Shumon Huque, University of Pennsylvania
October 30th 2007
This short document argues against the use of LDAP as a central authentication system. In a central authentication system, authentication credentials for users are typically stored on a single set of servers on the network, and a (potentially large) population of application servers employ this central system to verify the identity of their users.
The term LDAP Authentication is itself something of a misnomer since LDAP is not an authentication protocol. It is a directory access and management protocol. LDAP Authentication may more correctly refer to authentication mechanisms in the LDAP protocol itself designed to limit access to directory information, eg. using the SASL framework or an underlying transport mechanism that supports authentication, like TLS. What this document argues against is a specific use of LDAP to store and deliver authentication credentials to application servers so that they can authenticate their clients.
Strong authentication systems use cryptographic authentication, ie. passwords and/or long term keys are never transmitted over the network. Instead, they are used to perform a cryptographic operation that can be verified by the authenticating party, without actually sending the secret to that party. Examples of such systems include Kerberos and various public key authentication protocols.
If particular applications are incapable of performing cryptographic authentication, it is possible to limit the threat by making sure passwords are sent over an encrypted channel only to the central authentication server (or servers), which then asserts the identity of the authenticated party in some secure fashion to the application server. The Shibboleth software framework provides one generalized framework for doing this.
What is commonly called LDAP Authentication is actually a method of authentication that involves the use of a centralized LDAP service by the application to retrieve passwords or hashes of passwords, and then comparing it to the password supplied by the user via the application protocol. The assumption is that the application service will directly receive the username and password in some manner.
Another method of performing LDAP authentication is even simpler. It involves an LDAP server configured so that users need to authenticate to it. Application servers receive passwords over the network, then try to use the username and password to authenticate to the LDAP server using the LDAP bind operation. If the bind operation succeeds the application presumes that the user is successfully authenticated.
There are a number of problems with these approaches:
LDAP can be a very useful component of an overall authentication and identity management infrastructure. Managing information about users or user accounts is commonly done. RFC 2307 (An Approach for Using LDAP as a Network Information Service) describes one such approach. The eduPerson LDAP Object Class is widely used in the Higher Education community to define attributes of users. It may also be reasonable to use LDAP to house the actual authentication credentials, as long as those credentials are sufficiently protected and not being handed out over the network to application servers. For example, a Kerberos server infrastructure may decide to store the Kerberos database on a distributed LDAP backend to aid in replication and management of the database. Actual authentication however is performed via the Kerberos protocol. LDAP is also often used to store certificates in a PKI (Public Key Infrastructure) system.
A strong central authentication system should take great pains to ensure that authentication credentials are kept under tight security controls on only the most strongly defended servers. Using LDAP in a manner that requires a large number of application servers to handle sensitive user credentials is inconsistent with this goal and is consequently a grave security risk.