2.1. SASL Authentication to ApacheDS has been edited by Emmanuel Lécharny (Nov 19, 2008).

(View changes)

Content:
Work in progress

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.

Inbound --> decoder --> BindHandler <--> Backend #1, #2
Outbound <-- encoder <------'

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.

Inbound --> SaslFilter --> decoder --> SearchHandler <--> backend
Outbound <-- SaslFilter <-- encoder <-------'
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.

$ ldapsearch -s base -LLL supportedSASLMechanisms -x
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5

When anonymous authentication is disabled, queries below the RootDSE will require authentication. The following command will fail if anonymous access is disabled.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -x
SASL queries

CRAM-MD5 is a username/password mechanism.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -U hnelson -w secret -Y CRAM-MD5

DIGEST-MD5 is a username/password mechanism. DIGEST-MD5 also supports the concept of "realm."

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -U hnelson -w secret -Y DIGEST-MD5 -R example.com

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'.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -Y GSSAPI
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

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences