How to extend SASL?
alexey.melnikov at isode.com
Sun Mar 23 08:03:28 EDT 2008
Hadmut Danisch wrote:
Sorry that it took me so long to reply to this, I was hoping that
somebody else will pick this up ;-).
>I have a specific problem with the sasl library and want to propose some
>I am running a site with multiple users, with different services and
>Some of them, such as SMTP, support SASL directly. Others use LDAP,
>while LDAP itself works with
>SASL in several modes. There is SASL authentication in the LDAP protocol
>itself, but OpenLDAP is
>also able to forward plain passwords to the SASL library, if an LDAP
>password entry is of the form
>So all of those services which support simple authentication with plain
>passwords against LDAP only,
>can effectively be run against SASL without the need to support it. On
>the other hand, this is the only way to extend the LDAP authentication
>On that site and for certain reasons, we run two different proprietary
>So I would like to extend SASL to verify whether a given password is
>accepted by either of these methods. That's where trouble begins.
>The first problem is that the cyrus SASL plugin structure is
This statement is probably true, but this really depends on what you are
trying to do.
If you can verify password by reading it as cleartext from a password
store, then you should use auxprop API.
If you you don't have access to cleartext password, you should extend
>and documentation is poor.
>cyrus supports plugins for the mechanism, which requires the client to
>have the same mechanism. But I did not find plugins under the PLAIN
>methods for verification. (I found that deprecated auxprop method, but
I don't know why you've decided that auxprop methods are deprecated.
>no precise documentation about it.
>I then came to the conclusion that I had to extend the sasl
>authentication daemon, but found that I had to patch the source code,
>which is pretty bad idea on modern linux systems and breaks the package
>upgrade procedures. Would be much better if that daemon could load
>dynamic modules to verify passwords and try one after the other based on
>configuration (like /etc/nsswitch.com or libpam).
That would be a fine extension. On the other hand having a hardcoded
list of verification methods might be just enough, as this avoids
complexity associated with plugins.
>It seems as if the authentication daemon supported pam modules, but
>would not pass the full domain name, just the username part.
>Too many details of the cyrus implementation seem to be rather ad-hoc
>implemented than to be well planned and designed, a heap of patchwork
>Therefore I currently consider extending the authentication daemon or
>the library itself as something between not recommendable and not
>feasible until it has a good system to plug in authentication mechanism.
>What currently appears to be the best way would be to write my own
>daemon and to completely replace the cyrus sasl authentication or
pwcheck daemon *is* deprecated, you would be much better off
>But where could I find a precise spec of the protocol?
The documentation is not extensive (if not to say poor). But here is
what is in saslauthd-main.c:
The service speaks a very simple protocol. The client connects and
sends the authentication identifier, the plaintext password, the
service name and user realm as counted length strings (a 16-bit
unsigned integer in network byte order followed by the string
itself). The server returns a single response as a counted length
string. The response begins with "OK" or "NO", and is followed by
an optional text string (separated from the OK/NO by a single space
character), and a NUL. The server then closes the connection.
An "OK" response indicates the authentication credentials are valid.
A "NO" response indicates the authentication failed.
The optional text string may be used to indicate an exceptional
condition in the authentication environment that should be communicated
to the client.
>Another option would be to replace the PLAIN plugin.
IMHO, that would be a bad idea. Use auxprop API, if possible. Or write a
new password verification module as used by PLAIN. But this is similar
to extending saslauthd, except that you would avoid talking to an
>However, all of these are odd workarounds for shortcomings of the
>library. I recommend a redesign.
While I am periodically tempted to rewrite/replace large chunks of
libsasl, I actually think that the high level design of it (and not the
implementation) is about right. In particular support for auxprop
plugins and saslauthd are two architecturally important and well thought
More information about the Cyrus-sasl