Re: SASL authentication for OpenLDAP (ITS#477)

[Kurt@OpenLDAP.org]

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