[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5207) Password checking: external program

Buchan Milne wrote:

> So wouldn't the existing {SASL} scheme for userPassword (which allows a simple 
> bind to be authenticated against a SASL identity) be sufficient?

Not really, because SASL is not just a server plugin, it requires the
client to have SASL (and the plugins) as well. Unfortunately, this is
not the case in most scenarios.

Actually, SASL would the the solution of choice if the client supported
it, because SASL is able to transmit replies (challenges,...), but this
is possible only if all clients support SASL and as long as you are able
to install SASL clients on both sides.

Reality is, that too many LDAP clients don't support SASL, and even if
they do, you are in most cases not able to install SASL library on both

Furthermore, SASL mechanisms are limited to password handling. It is
sort of tricky or impossible to pass other authentication methods
through (e.g. any sort of cookie based authentication).

Would be nice if the client could perform just the basic LDAP
authentication and the password still be accepted even if it is a
cookie, one time password, or any other strange thing.

> Well, any implementation of this would have the same problems of the existing 
> {SASL} scheme, of losing some of the security SASL provides.

Well, as I said it would be pretty similar to SASL except for the fact
that SASL requires the client to

a) support SASL (i.e. has SASL software)
b) support the authentication SCHEME (i.e. has the particular SASL
c) has to pass through SASL messages if between client and LDAP (e.g.
   IMAP servers)

which is not the case at the moment.