RE: SASL LDAP plugin

["Howard Chu" <hyc@highlandsun.com>]

> -----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