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
Mark, Here is a copy of a message sent to the core team regarding command line options. Would it be possible for your changes to follow these suggestions: From: Kurt To: core Subject: command line options I recommend we use -Z to tell client to execute a StartTLS exop before any other option and -Y to specify use of a SASL mechanism. -ZZ would state that establishment of TLS is critical (ie: non-optional). Some SASL mechanism provide data integrity (signatures) and data security (encryption). I suggest -I and -E respectively. Specifying the option twice indicates that it's critical. We should provide options to enable these as well. ldapsearch -Z -Y external .... ldapsearch -Z -Y login .... ldapsearch -Y digest-md5 ... ldapsearch -I -Y digest-md5 ... ldapsearch -E -Y digest-md5 ... ldapsearch -IIEE -Y kerberos ... -U would be used for the Authentication identity (as needed). -X would normally be used as the Authorization identity. (-D cannot be used as, in a few rare cases, an independent bindname may be used by the SASL mechanism). Note: -I,-U are used by gateway clients. I'd prefer to adjust the gateway clients as needed to allow more meaning flag use. However, we could use other flags instead if there is objection. At 06:04 PM 3/13/00 GMT, adamson@cmu.edu wrote: >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 > Additional comments: I suggest -Y auto to enable sasl negotiation. As far as schema goes, likely best discussed on devel then, as appropriate, w/ IETF LDAPext and/or CAP WGs. I should be able to review your implementation soon... Kurt
changed notes
changed notes changed state Open to Suspended moved from Incoming to Software Enhancements
moved from Software Enhancements to Development
changed notes changed state Suspended to Closed
See devel mailing list discussions. Not committed.