Friday, November 30, 2007

Why use LDAP?

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. read more | digg story

3 comments:

Anonymous said...

I was curious to know why we need to go for LDAP, and here I have the answer, no other place I could see a better answer.

Anonymous said...

Thanks for the info. Nicely written.

Anonymous said...

I have never understood why anybody in the world would want to seriously use LDAP. The syntax is a nightmare, the structure is rigid (try to make a simple cross-select from 2 different tables) and one is in danger of growing a grey beard before mastering it. It is not true that ldap is easier to replicate than mysql: ldap replication is based on a dump which is then transferred to the second server; the same can be achieved just as easily via a mysql dump. Ldap searches are not faster, I cannot possibly imagine how a mysql database with indices correctly set could be slower in a select than ldap. There are some benchmarks on the internet already and they report that ldap is NOT faster than mysql. The licensing stuff is as valid for LDAP as for mysql. Concerning the standard for the internet, I only saw LDAP once as a backend (it was there for historical reasons) but mysql countless of times, but my experience might be skewed.

From my experience (worked with both), if we take the same amount of energy that one usually puts in understanding and working with ldap, and use it to learn SQL, one could end up with pretty good SQL-skills.