Reasons to store users' data in LDAP instead of RDBMS

Question

It is often said that using LDAP is a good way to store data about users. That\'s beacause users\' \"directory\" is hierarchical and it changes rarely. But in my opinion tha

Answer 1

This indeed does not exclude RDBMS as backend. See for example details on sql backend for slapd or look at the full list of backends.

Answer 2

Interoperability.

LDAP directories have a standard schema to represent a user, so common fields such as first name, last name and email address will be consistently named across different directory implementations. This is not the case with an RDBMS.

LDAP defines both the communication protocol and the query language. Compare this to SQL which is only a query language and each RDBMS implements its own communication protocol.

So there are many, many applications that can simply 'plug-in' to an LDAP directory as a user store, allowing you to centralise user management. (Of course, there are still compatibility issues between directory implementations, but these pale in comparison to having users stored in separate databases for each app).

Answer 3

The "L" in LDAP stands for Lightweight. One goal of LDAP is to be relatively simple to use and implement. If all you need to do is store information about users, you don't need the full flexibility (and potential headache ) of accessing your data via SQL. A limited interface as presented by LDAP should be easier. This is important if you want LDAP to be implemented and supported by everyone, including your os vendor and all your application vendors.

PS: If you wanted to, you could always implement an LDAP server by storing all the info in an RDBMS, and providing an LDAP interface to it :)

PPS: LDAP is a protocol, like HTTP. An RDBMS is an application, usually thought of as one that implements SQL, among other things. So to compare apples to apples, you would be better off contrasting LDAP with SQL or HTTP.

Answer 4

One good reason is for providing single sign on across many apps (which use the LDAP).

Answer 5

Interoperability, as has already been mentioned, is very much in LDAP's favour with some types of server software, although much of the software that integrate with LDAP require a specific schema so it's not necessarily as simple as just installing and configuring an LDAP service and off you go - you might need to add new elements in the schema for each app you want to interact with, and each application might have different limitations with regard to authentication (for example plain text password fields, password fields as MD5 or SHA hashes, etc).

A good LDAP service requires a fair bit of configuration knowledge, more so than creating a simple schema in a relational database. SQL DB's are still a fairly interoperable option and LDAP support is not as dominant as it once was. LDAP used to be the only option years ago, but many applications (like Apache) and operating systems (like Linux's PAM) can authenticate against SQL DB's like MySQL just as easily as LDAP servers as it's all handled by drivers that abstract the interface.

Where LDAP really shines is scalability. If you specifically want a place to hold user accounts for authentication and want to scale to multiple replicated servers - and handle tends of thousands of authentication requests a second, LDAP is an great option.

It's not that modern RDBMS's don't scale it's just that LDAP is (typically) even better at this because of the way it cascades replication through different tiers; particularly assuming you have a typical authentication database setup where it's mostly read-only with relatively few write operations, so you only need one way replication with all writes coming from a single source of truth.

Really though, an LDAP server is something to consider if you have a specific need to do so, like a specific application you want to be able to interoperate with that only integrates with LDAP, or if you are building a highly scalable authentication system (e.g. for an ISP or for a super-scalable web application - where you plan on having more than a couple servers dedicated just to authentication, and where they may be spread across the country or even across the globe).

The point someone has already made about having an LDAP front end on an RDBMS is very good one. A few companies - including Oracle (who have a vested interest in RDBMSs, of course) - have products that do specifically that. If you don't want the overhead of managing an LDAP service, or if you just want to manage all your users in a DB you can create views/joins with, but think you might need an LDAP service later, than it's a good option. OpenLDAP also supports a shell back end which can take in data from any source, including an RDBMS; I've used it with MySQL and it works well, although can be a little fiddly to set up the first time if you need to support a specific LDAP schema.

In summary, LDAP is great, but it's situation specific to interoperability and extreme scalability. If you have limited resources to manage and support one, it might not be worth the hassle of supporting, but if you are planning services like UNIX hosted POP/IMAP/SMTP or other third party software integration then it's certainly worth doing (and may even be your only viable option).

Oh and lastly be wary of what LDAP server you use if you do decide to implement one! They are not all created equal and the differences between them (in terms of performance and ease of management & configuration) can be quite stark.

OpenLDAP is a pretty safe bet, scales well and is fairly easy to use. Some applications work best / come with specific configuration files for a specific LDAP server (e.g. a lot of software on Solaris assumes you are using Sun ONE directory server) which you might not otherwise want to use - either because it doesn't perform as well, or is a pig to configure, isn't well supported, etc.

Answer 6

Microsoft has created a TechNet article discussing their Active Directory Application Mode (ADAM) product and it has a section comparing the differences between a Directories and Databases. The following is taken directly from the site.

Directories

• Optimized for search and read operations.
• Object-oriented, hierarchical data design. Data objects in the directory represent entities such as users, computers, and shared resources. These data objects can be organized hierarchically in containers.
• Does not use schemas.
• Designed for replication and distributed management.
• Precise security, down to the object and attribute level.
• Loose data consistency between replication partners.

Databases

• Optimized for write operations.
• Relational data design. Data is organized in tables of rows and columns. Data from one table can be linked to data in another table.
• Uses standardized, extensible schemas.
• Designed for central storage and administration of data.
• Less precise security, only down to the row and column level.
• Transactional — guaranteed data consistency. Referential integrity across relational tables and concurrency control with file and record locking.