RE: SASL LDAP plugin

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:54 PM 2002-06-13, Howard Chu wrote:
>> -----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,

okay, then maybe a "who be this?" operation (like whoami but
asks the question "what DN is associated with this (provided)
identity?".

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

Basically, you'd have a control which would contain an 
authentication or authorization identity (in authzid form).
The control should be marked critical and the base/target
DN should be empty.  Semantically, the DN associated with
the provided authzid is used as the base/target DN of the
operation.

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

It should be inappropriate to attach this control to the
bind operation.

Kurt





>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support