SASL authentication for OpenLDAP (ITS#477)

[adamson@cmu.edu]

Full_Name: Mark Adamson
Version: devel
OS: Solaris
URL: http://nil.andrew.cmu.edu/ldap/sasl
Submission from: (NULL) (128.2.122.223)


Hello all

   I've finished up the SASL authentication that Luke Howard started
in the OpenLDAP devel tree. A client program can now initiate a SASL
bind with the slapd server, and upon successful completion the server
side connection will be bound to a given DN. The SASL option of
authorizing to another DN is also supported, so that services like web 
servers or sendmail can authenticate as a server DN then switch to a
user DN to perform operations on the user's behalf.
   Just as the Kerberos IV authentication uses a "krbName" attribute
to map between the LDAP namespace and Kerberos namespace, I included
the use of a "saslName" multivalued attribute to map from LDAP to
SASL. This is so that slapd ACL's can specify LDAP names, not SASL
names. There is also an issue as how to specify what authenticated
DN's can authorize to what other DN's. There are many ways to do this,
and no solution will please everyone, but what I did was allow for a
multivalued attribute called "saslAuthorize" which can hold a regexp
of DN's to which that DN is allowed to authorize. Thus an entry for a
person who is an admin in a department might look like:
	dn: uid=adamson, ou=engineering, dc=cmu, dc=edu
	saslName: adamson@andrew.cmu.edu
	saslAuthorize: uid=.*, ou=engineering, dc=cmu, dc=edu
This entry means that I can authenticate to SASL as adamson@andrew.cmu.edu
and bind as that DN, then use SASL authorization to become any uid in
the engineering group. This authorization ability is similar to being
able to "su" to other users, and should be jealously gaurded.
   SASL binding is achieved by a call to ldap_negotiated_sasl_bind_s(),
and the authentication DN and optional authorization DN are passed
in. The authentication may require several messages between the client 
and server. Each message is sent in a BIND request to the server, and
server threads will service the bind step by step. After each step,
the thread will send its reply and then return the connection to the
pool of existing connections and go back to sleep. A server thread
will NOT stop and wait for the next authentication message from the
client, because broken or malicious clients could tie up server
threads indefinitely.
    I added SASL authentication to ldapsearch as an example. I grabbed 
three more flags from the command line:
   -c              use Cyrus SASL authentication
   -m mech         specify SASL authentication mechanism (e.g. KERBEROS_V4)
   -Z dn           use SASL authorization to become specified dn



A gdiff of my changes is available at

	http://nil.andrew.cmu.edu/ldap/sasl


-Mark Adamson
 Carnegie Mellon