Understanding LDAP (part 1) - Looking For Answers (
Page 3 of 5 )
Put very simply, LDAP is a protocol
designed to allow quick, efficient searches of directory services. Built around
Internet technologies, LDAP makes it possible to easily update and query
directory services over standard TCP/IP connections, and includes a host of
powerful features, including security, access control, data replication and
support for Unicode.
LDAP is based largely on DAP, the Directory Access
Protocol, which was designed for communication between directory servers and
clients compliant to the X.500 standard. DAP is, however, fairly complex to
implement and use, and is not suitable for the Web; LDAP is a simpler, faster
alternative offering much of the same basic functionality without the
performance overhead and deployment difficulties of DAP.
Since LDAP is
built for a networked world, it is based on a client-server model. The system
consists of one (or more) LDAP servers, which host the public directory service,
and multiple clients, which connect to the server to perform queries and
retrieve results. LDAP clients are today built into most common address book
applications, including email clients like Microsoft Outlook and Qualcomm
Eudora; however, since LDAP-compliant directories can store a diverse range of
data (not just names and phone numbers), LDAP clients are also increasingly
making an appearance in other applications.
Here's a simplified diagram
of how LDAP clients and servers work.
As you
can see, the system above comprises three LDAP servers, each one handling a
different section of the global directory. Client queries are either resolved
immediately by the server to which they are directed (if that server has the
requested information) or referred to another server for resolution. This
redundancy between servers is what makes LDAP so suitable for the distributed
nature of the Web - a single directory may be split across multiple servers in
different locations and merged together at leveraged connection points to work
as a single, unified database.
If you're familiar with how the Internet
Domain Name System (DNS) works, you'll see numerous similarities between that
model and the one described above - both are global directories split across
multiple hosts, both contain built-in redundancy and replication features, and
both include referral capabilities that make it possible to retrieve data that
is not available locally from other hosts in the system.{mospagebreak title=Up A
Tree} An LDAP directory is usually structured hierarchically, as a tree of nodes
(the LDAP directory tree is sometimes referred to as the Directory Information
Tree, or DIT). Each node represents a record, or "entry", in the LDAP
database.
An LDAP entry consists of numerous attribute-value pairs, and
is uniquely identified by what is known as a "distinguished name" or "DN".
Consider the following diagram, which illustrates:
If
you're familiar with RDBMS, it's pretty easy to draw an analogy here: an LDAP
entry is analogous to a record, its attributes are the fields of that record,
and a DN is a primary key that uniquely identifies each record.
Consider
the following example of an LDAP entry, which might help make things clearer:
dn: mail=joe@melonfire.com, dc=melonfire, dc=com
objectclass: inetOrgPerson
cn: Joe
sn: Somebody
mail: joe@melonfire.com
telephoneNumber: 1 234 567 8912
This is an entry for a single person, Joe Somebody, who works
at Melonfire. As you can see, the different components of the entry - name,
email address, telephone number - are split into attribute-value pairs, with the
entire record identified by a unique DN (the first line of the entry). Some of
these attributes are required and some are optional, depending on the object
class being used for the entry (more on this later); however, the entire set of
data constitutes a single entry, or node, on the LDAP directory
tree.
Wondering how a DN is created? Well, every entry in the directory
tree has what is known as a "relative distinguished name" or "RDN", which
consists of one or more attribute-value pairs and must be unique at that level
in the directory hierarchy. In the example above, for instance, the following
are all valid RDNs for the entry:
cn=Joe
or
cn=Joe+sn=Somebody
or
cn=Joe+sn=Somebody+telephoneNumber=12345678912
or
mail=joe@melonfire.com
In other words, there are no hard and fast rules as to which
attributes of a particular entry should be used for the RDN; the LDAP model
leaves this decision to the directory designer, simply specifying that the RDN
of an entry must be such that it can uniquely identify that entry at that level
in the DIT.
Now, since RDNs exist for each and every entry in the tree,
the DN for any entry is formed by appending the RDNs of all the nodes between
that entry and the root entry to each other. The DN thus makes it possible to
easily locate any node in the directory tree, regardless of its location or
depth in the hierarchy.
In order to better understand this, let's take a
simple example. Consider the following LDAP directory:
rdn: c=IN [dn:c=IN]
|
|
| --- rdn: o=Melonfire [dn:o=Melonfire,c=IN]
|
|
| --- rdn: ou=Executives [dn:ou=Executives,o=Melonfire,c=IN]
| |
| |
| | --- rdn: uid=sarah
[dn:uid=sarah,ou=Executives,o=Melonfire,c=IN]
|
| --- rdn: ou=Worker Bees [dn:ou=Worker Bees,o=Melonfire,c=IN]
|
|
| --- rdn: uid=joe [dn:uid=joe,ou=Worker
Bees,o=Melonfire,c=IN]
|
|
| --- rdn: uid=john [dn:uid=john,uid=joe,ou=Worker
Bees,o=Melonfire,c=IN]Now, in order to identify the node belonging to Joe Somebody
- in other words, to obtain the DN for Joe Somebody's entry - all you need to do
is add up all the RDNs between that entry and the root of the tree. Doing this,
you get
uid=joe,ou=Worker Bees,o=Melonfire,c=IN
In a similar manner, the DN for the node belonging to Sarah
would be
uid=sarah,ou=Executives,o=Melonfire,c=IN
while the DN for the Melonfire node would be
o=Melonfire,c=IN
Since LDAP entries are arranged in a hierarchical tree, and
since each node on the tree can be uniquely identified by a DN, the LDAP model
lends itself well to sophisticated queries and powerful search filters. For
example, I could restrict my search to a particular subset of the tree simply by
specifying a different base for the query to begin from, or query only against
specific attributes in the directory tree. Heck, I could even do both, and feel
like a Real Programmer!
