This site is in the process of being reviewed and updated.
Introduction
Apache Directory currently supports the CRAM-MD5, DIGEST-MD5, and GSSAPI SASL mechanisms. SASL is used during LDAP Binds to authenticate users. Additionally, with the DIGEST-MD5 and GSSAPI mechanisms, SASL can also provide message integrity (checksums) and, optionally, message privacy (encryption). When using SASL message privacy, connections do not need SSL to protect communications.
Architecture
SASL workflow is implemented in the LDAP Protocol Provider's BindHandler. At the start of a Bind, the BindHandler handles SASL negotiation. During SASL negotiation, the LDAP client is first authenticated. After successful authentication, an LDAP context is established and a SUCCESS message is returned.
Backend #1 is a lookup to authenticate the user using an administrative (internal) directory context.
Backend #2 is an LdapContext establishment for the user that is stored in the user's MINA session.
The DIGEST-MD5 and GSSAPI SASL mechanisms can provide message integrity and, optionally, message confidentiality by "wrapping" or "unwrapping" data with a security layer. After the Bind has completed the BindHandler will insert a MINA filter that handles security layer processing into the IoFilterChain for the session that was SASL-authenticated. All subsequent LDAP operations will be wrapped or unwrapped by the SaslFilter (assuming message integrity or privacy are negotiated). For example, a subsequent search would arrive wrapped and thus must be unwrapped by the SaslFilter prior to being ASN.1 decoded into a SearchRequest. Similarly, all outbound responses, including errors and unbinds, will be wrapped by the SaslFilter.
CRAM-MD5
Password must be stored as plaintext in the 'userPassword' attribute.
Username is matched to 'uid' under a base DN.
DIGEST-MD5
Password must be stored as plaintext in the 'userPassword' attribute.
Username is matched to 'uid' under a base DN.
Realm must match realms advertised by the LDAP server, but there is no multi-realm support yet.
GSSAPI
Principal name is matched to the 'krb5PrincipalName' attribute under a base DN.
No multi-realm support yet.
Principal configuration (user, service, krbtgt) can all occur on LDIF load.
Anonymous queries
RootDSE queries will never require authentication.
When anonymous authentication is disabled, queries below the RootDSE will require authentication. The following command will fail if anonymous access is disabled.
SASL queries
CRAM-MD5 is a username/password mechanism.
DIGEST-MD5 is a username/password mechanism. DIGEST-MD5 also supports the concept of "realm."
GSSAPI will use the Kerberos credentials of the current user. GSSAPI supports the concept of "realm," but the realm is part of the username, eg 'hnelson@EXAMPLE.COM'.
Resources
IMAP/POP AUTHorize Extension for Simple Challenge/Response
http://www.ietf.org/rfc/rfc2195.txt
Using Digest Authentication as a SASL Mechanism
http://www.ietf.org/rfc/rfc2831.txt
RFC 4422 - Simple Authentication and Security Layer (SASL)
http://www.faqs.org/rfcs/rfc4422.html
This document obsoletes RFC 2222.
Lightweight Directory Access Protocol (LDAP): Directory Information Models
http://www.faqs.org/rfcs/rfc4512.html
RFC 4513 - Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
http://www.faqs.org/rfcs/rfc4513.html
This document obsoletes RFC 2251, RFC 2829, and RFC 2830.
Simple Authentication and Security Layer (SASL) Mechanisms
http://www.iana.org/assignments/sasl-mechanisms
RFC 3829 - LDAP Authorization Identity Request and Response Controls
http://www.faqs.org/rfcs/rfc3829.html