Lightweight Directory Access Protocol (LDAP) directories and
LDAP authentication have become one of
the enterprise user infrastructure cornerstones. As the enterprise has
opened itself up to customer, business partner, vendor and wide-spread
employee access to pieces of most enterprise applications, the need to
know who the user is has significantly increased from a security
perspective. Who is the user trying to access an application? What is
the strength of authentication by which the application can trust the
user trying to access the application? What are the user's
The frequency with which to authenticate who a user is has also increased. Thus in medium to large enterprise it is not uncommon to have several thousand to several hundred of thousand identity look-ups per second.
The above are the reasons why LDAP directories and authentication have taken on such a dominant role in enterprise authentication. LDAP directories offer the following features:
In most medium to large enterprises, the authoritative source
for employee information is usually the Human Resource Management
System (HRMS). Figuring out what system is authoritative for customers,
contractors, temps, business partners and vendors is usally much more
It is very important before LDAP authentication is implemented the enterprise first determines which system or application will be authoritative for the identity data. This also means cleaning up the associated business processes dealing with identity creation, role changes and terminations. Often the authoritative identity source will have many identities in their data stores listed as active who are no longer active. This can create security holes in any LDAP authentication.
Next it's important that in cases where multiple data sources have the same identity information that a universal identity id be deployed. For example, if a user named John Jones is in the HRMS as J Jones, in the payroll system as John Jones, in the shipping system as JJONES etc, then it becomes important to know at the enterprise level a common id for John Jones. This usually means creation of a unique alphanumeric id for each user. Without this, the enterprise LDAP authentication won't work since John Jones won't know which id to use in authentication. Further, the handoff to the applications after LDAP authentication won't work since the LDAP directory has to communicate with the application that John Jones has successfully authenticated.
LDAP authentication relies upon the LDAP directory having the
most up to date identity information with which to do an authentication
against. This requires that the authoritative source be linked, at a
minimum, on a nightly batch basis, and in many cases, on a identity
event basis. In the old days, of a few years ago, interfacing LDAP
directories with authoritative source data bases was expensive and time
consuming to do. The synchronization of the LDAP directories with the
databases was critical and costly.
Today however, LDAP virtual directories are now mainstream tools. A LDAP virtual directory is one which sits in a virtual environment and has its sources of identity information derived from pointers to specific tables in data stores or, in other LDAP directories. LDAP virtual directories can usually be created in several hours or a few days and put into operation very quickly.
There are many ways of authenticating a user. These range from
the id and password (commonly referred to as "basic authentication"),
digital certificates, security tokens, smart cards and biometrics.
There are different reasons to use each type of authentication (refer
to the authentication strength portion of this website).
Once you have determined the type or types of authentication your enterprise is going to use, then you are ready to begin doing LDAP Authentication.
LDAP authentication is now very common in network operating
systems. Microsoft uses this in Win2003 with it's Active Directory. All
network operating systems today support the integration of LDAP
Authentication including Solaris, Novell, AIX, Linux and HPUX.
In each of these cases, the user usually enters in their id and password. The information may be presented as an online form or simply have an entry point for the id and password. This information is then sent to the LDAP directory (make sure the information is sent encrypted and not in open text).
The directory takes this information and compares it to the id and password stored in the LDAP directory. If it is the same, the LDAP authentication is successful.
In network operating systems, the network then takes over and proceeds with user authorization and allows them to use the network.
Single Sign On (SSO) systems mostly use LDAP authentication. The enterprise user logs on in the morning and sees normally a form based enterprise login screen. The user enters in their id and password. The SSO software then takes the information and sends it to the security server using an encrypted connection. The security server in turn then logs on to the LDAP server on behalf of the user by providing the LDAP server with the user's id and password. If successful, the security server then proceeds with any authorization and/or lets the user proceed to the application or resource they require.
Often times a simple LDAP directory authentication project hits trouble. These can be because of:
Having a good knowledgeable consultant early on in the design process can save your enterprise significant money and time while guiding you to avoid creating security holes with your SSO LDAP implementation.
SSO Strategy and Policies
Sign On Authentication Access
Control Authentication Authentication-Enterprise
Authentication Management User Authentication Authentication Federation Biometric Authentication PKI Authentication Token Authentication Wireless Authentication Document Authentication Authentication - Outsourcing