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.
