How to extend SASL?

[Alexey Melnikov]

Hadmut Danisch wrote:

>Hi,
>  
>
Hi Hadmut,
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
>improvements:
>
>
>I am running a site with multiple users, with different services and
>authentication procedurs.
>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
>
>  {SASL}user
>
>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
>procedures.
>
>On that site and for certain reasons, we run two different proprietary
>one-time-password methods.
>
>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
>insufficient
>
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 
saslauthd.

>and documentation is poor.
>
I agree.

>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
>and extensions.
>
>
>
>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.
>
pwcheck daemon *is* deprecated, you would be much better off 
extending/rewriting saslauthd.

>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 
external service.

>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 
through features.