Devdas Bhagat <[EMAIL PROTECTED]> writes:
> <Plain Text>
> The current implementation of SASL does not support remote
> connectivity.
I believe the basic problem is that you don't see where SASL fits
in. Your comment is much like saying that you can't use an orange to
chew gum.
> What most people are looking for is a way to connect to a remote SASL
> database with minimal configuration.
Let's not over generalize. In this specific context, people are trying
to authenticate using LDAP.
What does this really mean? This means a user is sending a password to
the IMAP server. The IMAP server then has to go to a LDAP server to
determine whether or not the password is correct.
Where does SASL fit in?
SASL is the means by which protocols (e.g. SMTP, IMAP, LDAP, etc.) can
distance themselves from authentication mechanisms (e.g. Kerberos,
CRAM-MD5, DIGEST, etc.). This way you do not need to specify in EACH
protocol how to deal with each and every authentication mechanism that
currently exists and that will come to exist in the future.
The protocol specifies how to do deal with SASL. SASL specifies how to
deal with the authentication mechanism. If you want even more
details, take a look at http://www.imc.org/ietf-sasl/.
Specifically, at least read sections 1 and 3 from
http://www.ietf.org/internet-drafts/draft-myers-saslrev-01.txt
The other complication here is plain text passwords (i.e. clients
using LOGIN rather than AUTHENTICATE). In this case, the imap server
also needs to pretend to be the authentication client and handing the
password over to something else and asking if it is correct or not.
The current expectation is that saslauthd will fit the role as the
intermediary when you have the actual password. There are already
mechanisms for DCE, Unix passwd, Kerberos v4, PAM, remote imap, shadow
passwords, and DEC's SIA. It should be very easy to modify a mysql
pwcheck to be a mechanism and whatever else you want. We'll probably
also provide a Kerberos 5 one by ripping out the code from
lib/checkpw.c.
Walter
