Re: identity assertion

[Pierangelo Masarati <ando@sys-net.it>]

On Thu, 2006-01-19 at 16:44 -0600, Eric Irrgang wrote:
> If you want to be able to do a simple bind as one DN but perform actions
> as another DN, you need to use some sort of identity assertion.  Is there
> a way to do this without using back-ldap?

Yes.  Just use proxyAuthz control (that's what back-ldap does, by the
way).

> 
> Specifically, I'm trying to work around the lack of ACL access to the
> config backend by allowing specific DNs to assert the cn=config rootDN.
> I've got rootdn for cn=config set to cn=config,dc=test and an entry in a
> bdb backend for cn=config,dc=test with a authzFrom attribute set.
> 
> So I just need to bind as a user that is authorized with the authzFrom and
> assert the cn=config,dc=test identity, right?

Yes.

> 
> The only way I could think to do that was to try to set up another virtual
> naming context of something like cn=admin and use some sort of rewriting
> so that cn=config,cn=admin points at cn=config.
> 
> So I'm trying to set up an ldap backend that will proxy the bind through
> to the dc=test backend and then assert the identity of cn=config,dc=test
> so that the authorization is handled at dc=test via the authz-policy from.
> 
> Is this the right approach?  I guess one thing I'm a little unclear on is
> what exactly is the authcID?  That's what has to match the authzFrom
> attribute, right?  Is it basically just the bind DN in a simple bind
> situation?
> 
> So far, a simple slapd config looks like the following, but I think slapd
> is first authenticating the client by proxy and then rebinding anonymously
> to try to assert the cn=config,dc=test identity.
> 
> database	config
> rootdn		cn=config,dc=test
> 
> database	bdb
> suffix		dc=test
> ...
> 
> database	ldap
> suffix		cn=admin
> uri		"ldap://localhost";
> idassert-bind	mode=self
> 		bindmethod=simple
> 		authzID="dn:cn=config,dc=test"
> overlay		rwm
> rwm-suffixmassage	"cn=admin" ""
> 
> 
> I connect to localhost, do a simple bind as a real user, try to perform
> and operation on cn=config,cn=admin, hoping that the operation will be
> relayed to cn=config with an effective identity of cn=config,dc=test, but
> I get insufficient access errors and the logs indicate that before the
> identity assertion there is an anonymous bind.  Isn't the mode=self
> supposed to take care of that?  Does my ldap database section need to have
> 'idassert-authzFrom "dn:*"'?
> 
> Suggestions, please?
> 
> I get the impression that I'm supposed to be using the extra features of
> SASL binds but I was hoping not to open that can of worms for a while.  Do
> I just need to go the SASL route?  Is there a way to move to SASL with my
> current SSHA userPassword credentials intact?

Authz and SASL cross each other many times, but they're different and
totally separated things.  Perhaps you're distracted by the fact that
SASL has the notion of authorization built-in.  What you need is set up
slapd so that authorization is at all allowed; then, you need to allow
the authorization you're trying to use.  Note that since the cn=config
rootdn is not going to be a real entry, you won't be able to add any
"authzFrom" to it; you'll have to add "authzTo: dn.exact:cn=config" to
the entry of the identity you're binding as, and allow "to"
authorization by using "authz-policy to".  Note that, as indicated in
slapd.conf(5),

                                                             Use of
    authzTo rules can be easily abused  if  users  are  allowed  to
    write  arbitrary  values  to  this  attribute.   In general the
    authzTo attribute must be protected with ACLs  such  that  only
    privileged  users  can  modify  it.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------