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 that doesn't exclude using RDBMS. What might be reasons to use LDAP? I guess that storing multi-valued fields or adding custom fields in LDAP might be easier but it can be done in database too (unless you have many records)

Answer 1

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

Answer 2

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 3

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 4

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.

A good LDAP service requires a fair bit of configuration knowledge too, more so than creating a simple schema in something like like MySQL. SQL DB's are still a fairly interoperable option, LDAP support is not as uniquely dominant as it once was. Many applications (like Apache) and operating systems (like Linux's PAM) can authenticate against SQL DB's 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 excellent option. It's not that modern RDBMS's aren't good enough to do this, it's just that LDAP is (typically) even better because of the way it cascades replication through different tiers. You can do that with a few RDBMS replication systems, but in practice not all (particularly when it comes to doing it reliably with dozens of servers and really huge authentication databases, where queries tend to be mostly read operations so where one way replication is an acceptable model).

Really though, looking at an LDAP server is something to consider if you have a specific need to do so, like a specific package you want to be able to interoperate with, or if you are building a high volume authentication system (e.g. an ISP or large organisations authentication platform - where you plan on having more than a few servers just dedicated to authentication alone, 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, obviously) - 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 perfectly valid option. OpenLDAP supports a shell back end which can take data from any source, including an RDBMS, I suspect others can too.

In summary, LDAP's 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 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 difference's between them (in terms of performance and ease of management & configuration) can be quite stark.

Answer 5

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.