How to extend SASL?

[Hadmut Danisch]

Hi,

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 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
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).

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. But where could I find a precise spec of the protocol?
Another option would be to replace the PLAIN plugin.


However, all of these are odd workarounds for shortcomings of the
library. I recommend a redesign.


regards
Hadmut