Timo Sirainen wrote:
For plaintext authentication you can use authentication binds and have the password stored on LDAP side in any way you want.
For non-plaintext authentication Dovecot needs the secret in plaintext or some other specific format. LDAP doesn't support "SASL forwarding".
Neither one doesn't help in this particular case.
I need to port a proprietary, non-publish one time password authentication method (not compatible with opie/skey) from older software into SASL or LDAP, to make it available for several unix applications.
The current plan is to implement a plugin for cyrus-sasl which is used by most sasl-aware applications, and thus to have the openldap server accept sasl authentication for those applications which allow to authenticate against an LDAP server, not just with plaintext passwords, but with SASL as well.
As far as I know dovecot does (or version 1.1) will support SASL methods, but does implement them itself, so does not work with a cyrus-sasl plugin and does not work against an LDAP server.
Since SASL authentication is implemented as a communication protocol passing opaque byte sequences between client and servers, the idea was whether dovecot could act like a SASL proxy, i.e. passing the SASL traffic between the IMAP client on one side and the LDAP server on the other side just through without touching it and waiting for the result of the authentication process.
A second method intended to be implemented is to pass web authentication (e.g. if a user authenticatis with SSL client certificates over HTTPS) through webserver - webmailer - IMAP Server -Authentication database which could also be implemented as a SASL plugin.
Therefore would be nice to have a SASL pass through without the need to modify dovecot or teach dovecot new authentication methods
regards Hadmut