FW: SASL authentication for OpenLDAP (ITS#477)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Forwarded to devel for discussion...

>Date: Mon, 13 Mar 2000 18:04:22 GMT
>From: adamson@cmu.edu
>To: openldap-its@OpenLDAP.org
>Subject: SASL authentication for OpenLDAP  (ITS#477)
>Comment: OpenLDAP "openldap-bugs" Mailing List <http://www.OpenLDAP.org/>
>List-Archive: <http://www.OpenLDAP.org/lists/openldap-bugs>
>
>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
>
>
>
>