tags:

views:

846

answers:

9

I've been in touch with LDAP in many projects I've been involved in but, the truth be told, I don't really understand it. I thought it was just a person directory but after I discovered that it can contain any objects in a hierarchical structure.

I installed openldap in my box and I found many tutorials regarding just the installation.

What is LDAP? What are the scenarios where LDAP is the right choice? What are the LDAP concepts I should know for working with it? What are the advantages of LDAP? Is it used just because old applications used it? Is there a good doc anywhere on internet explaining all this questions?

UPDATE: Complementing the answers I found this link which contains a quick start guide for LDAP n00bs (like me): http://www.go4expert.com/forums/showthread.php?t=4814

+1  A: 

LDAP is just a protocol, the wikipedia article explains it adequately http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

Its a way to query an underlying organizational structure like Microsoft's Active Directory. You can use LDAP queries to get all kinds of information about users, use it for setting application rights, etc.

kscott
+1  A: 

This link will explain LDAP http://blogs.sun.com/raghuvir/entry/ldap

We use LDAP in our office for email address lookups company wide. We use it as a single source sign on service for our internal apps as well.

RedWolves
+3  A: 

LDAP has O(1) read performance, in exchange for O(something worse) write performance. It's ideal for data that's accessed frequently, but changed rarely - directories of people, machine names and addresses, and so on. (hence the acronym: Lightweight Directory Access Protocol.)

LDAP is the right choice where the pain of using a database that isn't relational, in terms of decreased developer familiarity and strange performance characteristics, is less than the gain of blindingly fast read access.

DDaviesBrackett
please get your O()'s right. they don't mean what you think
Javier
to clarify: what I meant was that retrieval times don't depend on the number of elements in the datastore (i.e. queries don't get slower the bigger the table is). Inserts do, though, in most LDAP implementations.
DDaviesBrackett
Any ldap server worth its salt, keeps an index on the dn (aka primary key) and lets you define additional indices to optimise common queries.
snoopy
+2  A: 

LDAP is an access protocol; it only provides an API to the underlying technology for which you are trying to find applications - a directory service. OpenLDAP is one of the open source directory services; Sun has another implementation called OpenDS. Active Directory and Novell NDS are another two commonly seen in the field.

The directory can be used for storing information about any sort of resource, and the relationships between the resources - for example, rights of a user to a directory, a printer, or a network access device.

Tetsujin no Oni
+12  A: 

What is LDAP? What are the scenarios where LDAP is the right choice?

At its core, LDAP is a protocol for accessing objects that are suitable for storage in a directory. Whether something is "suitable" is an entirely subjective determination that's left up to implementers, but typically this means collections of many objects that each have infrequently (or never) updated data, where each object has an obvious or canonical way to be looked up:

  • a phone book (look up by name or by phone number)
  • titles in a library (look up by title, author, etc.)
  • tenants in a building (look up by floor, suite, name, etc.)

and so on.

Note that LDAP itself is just a protocol and doesn't provide any actual storage -- in much the same way, HTTP doesn't imply anything about whether you're using Apache, Jetty, Tomcat, Mongrel, et al. as a web server. (One problem with LDAP in general is the confusing reuse of names to mean different things. Wikipedia has a good section on this.)

John Feminella
+1  A: 

In one of my old workplaces we used LDAP as our primary user authentication system.

This in turn provided our various systems with information which dept. they belonged to, where they should mount their home directories, contact information, employee management.

Not necessarily controlled by LDAP, but other things that we had mixed to work through LDAP was the existence of SQL users, K4, samba and email account generation.

JensenDied
+1  A: 

I am working part time and a full time student. My curriculum encourages (read requires) many group projects.

I have used openLdap and phpLdapAdmin to control access to my Subversion and Mercurial repos, Trac projects, Hudson, etc. It wasn't easy to install, but the time saved in administration was a God send.

If you have projects where you will have many groups of people who need to be able to use different resources, it is a good tool.

Summers Pittman
Depending on the scale and scope of the user base, sometimes files are sufficient. Sometimes a DB, sometimes LDAP. It often depends on scale. LDAP Servers in general being optimized for this usage, often scale better.Less clear cut of a case with smaller usage cases.
geoffc
+2  A: 

DITs are a hierarchical description scheme that lend themselves to B-Tree algos very nicely, resulting in tremendous search performance in most cases. Directory Server like OpenDS return indexed searches in micro-seconds, whereas RDBMS systems are much slower. Directory Servers (often called LDAP servers) trade resources (RAM, CPU) for fast read response. RDBMS systems provide greater functionality in terms of management of data in question. Need speed with few or zero updates, simplicity, and small network protocol? Use a Directory Server. Need data management and mining capabilities, and/or high rate-of-change of the database with relational aspects defined between data? Use an RDBMS (MySQL is your best bet here).

Good combination of descriptive and prescriptive. Welcome to SO!
Tetsujin no Oni
A: 

One perspective I like to harp on is LDAP is an app on top of a persistence store and a database is a persistence store. Both can be used to store user information.

LDAP gives you a hierarchy which is harder to do in a database. You can make a hierarchy in a database but it's harder to do things like delegation (these rows belong to you only) or ACLs on rows. So pushing security problems out of the database is easier if you use LDAP for storing user identities. Trying to solve it in the database is weird.

At the same time, LDAP is terrible for reporting against (transform LDAP to a DB for reporting). Storing attributes deep in the tree that need to be searched quickly can be problematic for performance (don't do this, have a DB on the side or try to flatten the query by redesigning your DIT). Storing attributes all over the place in a really deep DIT is just bad LDAP or system design but sometimes it's unavoidable if you're tied to a vendor product or legacy app.

milkfilk