Re: SASL LDAP plugin

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

At 08:07 AM 2002-06-13, Howard Chu wrote:
>Fyi, I've just gotten this LDAP auxprop plugin working with the Cyrus sample
>server. So now arbitrary servers can perform SASL authentication against the
>secrets stored in LDAP.
>
>Any suggestions on where to put the source file? It's a single C source
>file, needs to #include ldap.h and a variety of sasl header files. The
>resulting shared object needs to be installed in /usr/lib/sasl2 (or wherever
>the SASL2 plugins are installed).
>
>The code has these basic pieces:
>
>plugin_init - grabs ldap_uri, ldap_id, ldap_pw, ldap_mech, and ldap_rc from
>the server's SASL config file. The ldap_uri is required, the rest are
>optional. You can use the ldap_rc keyword to point to an LDAP config file
>that will be read when the LDAP library initializes itself.
>
>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.

Kurt