LDAP

Once upon a time, in the dim and distant past (the late 70's - early 80's) the ITU (International
Telecommunication Union) started work on the X.400 series of email standards. This email
standard required a directory of names (and other information) that could be accessed across
networks in a hierarchical fashion not dissimilar to DNS for those familiar with its architecture.

This need for a global network based directory led the ITU to develop the X.500 series of
standards and specifically X.519, which defined DAP (Directory Access Protocol), the protocol
for accessing a networked directory service.

The X.400 and X.500 series of standards came bundled with the whole OSI stack and were big,
fat and consumed serious resources. Standard ITU stuff in fact.

Fast forward to the early 90's and the IETF saw the need for access to global directory services
(originally for many of the same email based reasons as the ITU) but without picking up all the
gruesome protocol (OSI) overheads and started work on a Lightweight Directory Access
Protocol (LDAP). LDAP was designed to provide almost as much functionality as the original
X.519 standard but using the TCP/IP protocol - while still allowing inter-working with X.500
based directories. Indeed, X.500 (DAP) inter-working and mapping is still part of the IETF
LDAP series of RFCs.

A number of the more serious angst issues in the LDAP specs, most notably the directory root
naming convention, can be traced back to X.500 inter-working and the need for global
directories.

LDAP - broadly - differs from DAP in the following respects:

1. TCP/IP is used in LDAP - DAP uses OSI as the transport/network layers

2. Some reduction in functionality - obscure, duplicate and rarely used features (an ITU
speciality) in X.519 were quietly and mercifully dropped.
3. Replacement of some of the ASN.1 (X.519) with a text representation in LDAP (LDAP
URLs and search filters). For this point alone the IETF incurs our undying gratitude.
Regrettably, much ASN.1 notation still remains.

LDAP Overview

Technically, LDAP is just a protocol that defines the method by which directory data is accessed.
Necessarily, it also defines and describes how data is represented in the directory service (the
Data (Information) Model). Finally, it defines how data is loaded (imported) into and saved
(exported) from a directory service (using LDIF). LDAP does not define how data is stored or
manipulated. Data storage and access methods are automagical processes as far as the standard
is concerned and are generally handled by back-end modules (typically using some form of
transaction database) within any specific LDAP implementation.
LDAP defines four models which we list and briefly describe - you can then promptly forget
them since they bring very little to the understanding of LDAP.

1. Information Model: We tend to use the term Data Model, in our view a more intuitive
and understandable term. The Data (or Informational) Model defines how the information
or data is represented in an LDAP enabled system - this may, or may not, be the way the
data is actually stored on physical media since such grubby details lie outside the scope
of the LDAP standards as described above.
2. Naming Model: This defines all that 'dc=example,dc=com' stuff that you stumble across
in LDAP systems. We stick pretty much to the specifications here because the terms are
so widely used.
3. Functional Model: When you read, search, write or modify the LDAP you are using the
Functional Model - yipee!
4. Security Model: You can control, in a very fine-grained manner, who can do what to
which data. This is complex but powerful stuff. We progressively introduce the concepts
and have dedicated a specific chapter to it. To begin with - forget security. You can
always go back and retro-fit security in LDAP. Where you cannot retro-fit, we reference
security implications in the text. This model also encompasses wire-level security such as
TLS/SSL. Good, solid, mind numbing stuff.

The scope of the LDAP standards is shown in the diagram below. The red stuff (1,2, 3, 4) is
defined in the protocol (the various RFCs that define LDAP). What happens inside the black
boxes (or in this case the green, yellow and mauve boxes) and on the black line to the
Database(s) (5) is 'automagical' and outside the scope of the standards.
Each component is briefly described here, in a bit more detail below and in excruciating detail in
subsequent chapters. But there are four important points first:

1. LDAP does not define how data is stored, only how it is accessed. BUT most LDAP
implementations do use a standard database as a back-end and indeed OpenLDAP offers
a choice of back-end database support.
2. When you talk to an LDAP server you have no idea where the data comes from: in fact
the whole point about the standard is to hide this level of detail. In theory the data may
come from one OR MORE local databases or one OR MORE X.500 services (though
these are about as rare as hen's teeth these days). Where and how you access the data is
an implementation detail and is only important when you define the operational
configuration of your LDAP server(s).
3. Keep the two concepts - access to the LDAP service and operation of the LDAP service -
very clearly separate in your mind. When you design a directory based system figure out
what you want it to do (the data organization) and forget the implementation. Then figure
out as a second phase where the data is and how and where you want to store it - during
LDAP operational configuration.
4. A number of commercial database products provide an LDAP view (an LDAP wrapper or
an LDAP abstraction) of relational or other database types.

LDAP Usage Summary

So what are LDAP (Directory) advantages and why would any sane human being use a
directory?

Before attempting to answer the question let's dismiss the tactical issue of performance. In
general, RDBMS systems are still significantly faster than LDAP implementations. This is
changing with the development of second generation Directory Servers but while RDBMS will
always remain faster than LDAP the gap is declining significantly to the point where, assuming
you compare like with like (a measured network initiated transaction), the differences will
become increasingly trivial. Unless, of course, you update a highly indexed attribute on every
operation - in which case you deserve everything you (don't) get.

So why use LDAP? Here is our list of key characteristics which make the (currently) high level
of pain worthwhile.

1. LDAP provides a remote and local data access method that is standardized. It is thus
possible to replace the LDAP implementation completely without affecting the external
interface to the data. RDBMS systems mostly implement local access standards, such as
SQL, but remote interfaces are always proprietary.
2. Because LDAP uses standardized data access methods, LDAP Clients and Servers may
be sourced (or developed) independently. By extension of this point LDAP may be used
to abstract the view of data contained in transaction oriented databases, say for the
purpose of running user queries, while allowing the user to transparently (to the LDAP
queries) change the transactional database supplier.
 3. LDAP provides a method whereby data may be moved (delegated) to multiple locations
without affecting any external access to that data. By using referral methods LDAP data
can be moved to alternate LDAP servers by changing operational parameters only. Thus,
it is possible to contruct distributed systems, perhaps with data coming from separate
autonomous organizations, while providing a single, consistent, view of the data to its
users.

4. LDAP systems can be operationally configured to replicate data to one or more LDAP
servers or applications without adding either code or changing the external access to that
data.

These characteristics focus exclusively on the standard nature of LDAP data access and do not
consider the ratio of reads to writes which, as noted above, depend on the number of operational
indices maintained. They implicitly discount the use of LDAP systems for transaction processing
- though there are signs that some LDAP implementations are looking toward such capabilities.