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 sides.
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 plugin) c) has to pass through SASL messages if between client and LDAP (e.g. IMAP servers)
which is not the case at the moment.
regards Hadmut