Why use LDAP?

RedHat Inc.

The main benefit of using LDAP is that information for an entire organization can be consolidated into a central repository. For example, rather than managing user lists for each group within an organization, LDAP can be used as a central directory accessible from anywhere on the network. And because LDAP supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS), sensitive data can be protected from prying eyes.

LDAP also supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited for the type of information the server is to disseminate. Because LDAP also has a well-defined client Application Programming Interface (API), the number of LDAP-enabled applications are numerous and increasing in quantity and quality.

PerlLDAP:

XX's Blog:

Why LDAP?

The question is a good one and I think as LDAP proliferates across more systems, many people will have the same question - and it deserves a good answer, so here is my two-cents-worth.

What we are really talking about is directory services, not just the protocol. Directories have some serious advantages over DBMS. Databases are optimized for OLTP (online transaction processing), but not for performing quick searches of information that is frequently used, but not updated constantly. In other words, Directories can deliver data very quickly (read) compared to a DB, but handles updates (write) slower in comparison to databases.

Features and Benefits using LDAP

§ Cross-platform functionality and industry standards-based (important consideration for future growth and deployments)

§ Widely accepted standard for the Internet

§ Inexpensive since licensing is usually not based on number of connections or clients open source directories are widely available. Also, replication and synchronization features are usually built-in rather than requiring a separate license as is the case for many databases.

§ Replication and synchronization is easy compared to complex DBMS implementation with highly specific SQL script requirements.

§ ACI’s for delegated administration so you can setup accounts that are highly specific in what administration functions a group has {e.g. an account may only allow for phone numbers to be updated, another for new objects (name, email, phone number) to be inserted, but not deleted or existing objects modified}

§ High Performance, since directory data is store hieratical you have very high availability over DBMS, sometimes up to 10 times higher.

Sample Use Cases.

The following is a short list of common uses of directory services since these uses are data profiles that are fairly static and do not have deep relationships – they are stored as relatively “flat” trees.

§ Phone / Address book

§ Infrastructure Resource List (ip addresses, etc)

§ Public Certificates

§ User credentials, groups, roles (for authentication/ authorization)

Directories are also more secure and can keep credentials “locked” and unable to read or copy from an outside source, and you can do in a database. Directories are based on a hierarchal storage schema, a “tree” structure. Information that would be able bi-directionally in a database are not available in this manner in a directory. Items that are lower in the hierarchy could be read, but data higher in the hierarchy are not available to the client. So you could read a person’s contact information, but not necessarily be able to see what accounts he has, or other people in a group that she is a part of. In a database, records are stored relationally, so if you can read a person in a group, you can read the group and theoretically see the records of everyone in the group if you have direct access to the tables, not true in a directory.