[Date Prev][Date Next]
Re: identity assertion
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
> 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?
> 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
> 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
> 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
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.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA