Re: external authentication in openldap

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

Here are my thoughts in this area:
For in-directory password storage, the userPassword attribute
should hold user's password in clear text.  If one wants LDAP
simple authentication, then this uses userPassword directly.
If one wants to use SASL/DIGEST-MD5 or other SASL password
mechanisms (including PLAIN), then this also should use
userPassword.  This is all in HEAD.

If one wants to use non-directory password storage, Cyrus
SASL managed storage should be used.  This can be SASLdb,
pwcheckd (or its SASL2 replacement), or whatever.  For
SASL password mechanisms, nothing is needed.  For LDAP
simple, we need a mechanism which tells slapd to use
SASL instead of userPassword.  Currently that's {SASL}.
Another mechanism could be provided.  Basically, I suggest
a regex-based mechanism.  If a regex matched the bind name,
a second regex would be used to map this DN to a SASL
authentication identity (w/ realm).

Another approach would be to have an attribute that, if
present in the entry, would contain the identity (which
is basically what you suggest).   I would suggest a
saslName attribute type and a saslAuthUser auxiliary
object class.  (Yes, I would make it SASL specific.)

Both approaches could be implemented....


At 11:30 AM 2002-06-06, Luke Howard wrote:

>>>Probably the easiest thing (ie. least intrusive) to do is to write a
>>>SASL plugin for OpenLDAP. For this to be useful in your application
>>>you would probably need a way to have simple bindRequests turned into
>>>PLAIN SASL bindRequests -- thoughts?
>>
>>Use the {SASL} userPassword scheme...
>
>Ah. It would be useful if this could be applied globally, so that (for
>example) we could use the userPassword attribute for secret storage.
>
>In the application I'm thinking of, another attribute (authAuthority)
>is responsible for selecting the authentication mechanism, which may
>or may not store its secrets in the directory. We could write a SASL
>password checking plugin that reads this attribute, along with
>userPassword, and does the necessary work to authenticate the user.
>(This would take advantage of the SASL auxprop plugin built into
>slapd.)
>
>If the userPassword attribute is used to select SASL for password 
>checking, then it can't be re-used for in-directory secret storage.
>(I know there isn't really any argument for using a SASL plugin to
>perform PLAIN password checking against cleartext passwords when
>liblutil already has the necessary logic.)
>
>Moreover, if we wish to use the hypothetical plugin to authenticate
>all users, we would have to populate every user's userPassword
>attribute with {SASL} + their authentication ID. I would prefer to
>be able to flick a switch that said "use sasl_checkpass() for all
>simple binds, using the user's DN as their authentication ID".
>
>Thoughts?
>
>-- Luke
>--
>Luke Howard | lukehoward.com
>PADL Software | www.padl.com