[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: SASL LDAP plugin
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> At 08:07 AM 2002-06-13, Howard Chu wrote:
> >lookup - calls ldap_initialize, sets the LDAP session to
> LDAP_VERSION3, does
> >an interactive SASL bind with ldap_id as the authcid, and the
> SASL client's
> >username as the authzid. Then does a WhoAmI, then does an
> ldapsearch on the
> >returned name (which must be a DN) to retrieve the requested SASL
> >attributes,
> >and then does ldap_unbind.
>
> I note that this actually requires the application server to have
> proxy authorization rights to the authcid, instead of just
> read rights to authcid's userPassword.
>
> Another approach might be to add a fetchUserPassword extended
> operation which returned the userPassword for an authcid. Then
> the application server could maintain a session long term with
> the LDAP server, establishing authentication/authorization/security
> layers as desired, then issuing fetchUserPassword on an as
> needed basis. Access control wise, the application server would
> just need read to the authcid's userPassword.
That sounds interesting. Except, the SASL auxprop API is supposed to allow
lookup
of arbitrary attributes, so this isn't quite enough. How about a new control
mapNameToDN that can accompany any operation, and causes the server to
perform the SASL name mapping steps on the request's dn/basedn before
handling the request? Then it's just a matter of using the ldap Search
operation to retrieve any info, and ldapmodify/whatever to update passwords
in a single step. (I guess this control would be redundant on a SASL Bind
request, but it should be harmless...)
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support