[Date Prev][Date Next]
> -----Original Message-----
> From: Pierangelo Masarati [mailto:firstname.lastname@example.org]
> The initial use of slap_parse_user() in parseProxyAuthz
> was intended to allow clients to specify a realm in the
> proxyAuthz control, but no mech was allowed.
> When we decided to condition the possibility of a realm
> in a used ID specification on the presence of a mech,
> this was making user realm specification impossible in
> proxyAuthz, so I added the "fake" "AUTHZ" mech to proxyAuthz
> control simply as a means to allow the possibility of a mech.
> parseProxyAuthz() desn't need to break the incoming authzID
> except for these sanity checks.
Well... specifying the realm is irrelevant, so allowing a fake mech is
unnecessary. The sanity check is unnecessary, the call to slap_sasl_getdn()
would simply fail if any of those fields are provided.
> > Now, as to the "AUTHZ" pseudo-mech and where/when it gets used... I
> > guess the purpose here is to distinguish proxying via SASL Bind from
> > proxying via proxyAuthz control, yes? So in an LDAP user's entry, a
> > saslAuthzTo rule for "u:joe.DIGEST-MD5" allows the user to SASL Bind
Of course I meant "u.DIGEST-MD5:joe" above.
> > using DIGEST-MD5 with the authzID set to "u:joe", but not for any other
> > mechs, and not for proxyAuthz control. Whereas an unqualified rule
> > allows all mechs and the proxyAuthz control. Yes?
This raises another point, which is vaguely related to the problem of
authorizing use of controls in the first place. I think it would be useful to
restrict the proxyAuthz control based on the LDAP Operation. E.g., I may only
want to authorize someone to proxy as me for Add operations, and nothing
else. This is not quite the same as the ACLs, nor do we need to duplicate ACL
functionality here. But it's something to consider.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support