~ Introduction ~

LDAP is a client server protocol for accessing directory service. The inspiration behind LDAP was to create a "lightweight" protocol to access X.500 directories ,whose naming model is explicitly stated and hierarchical, so that clients could run without high demand for computing resources and complexity.

The first spec for LDAP is described in RFC 1487.

LDAPv2 is explained in RFC 1777 & 1778.

LDAPv3 is a proposed draft standard ( RFC 2251-2256).

~ Why LDAP and not X.500? ~

1. X.500 uses highly structured data encodings for its directory entry model.

2. LDAP adopts a simple, string-based representation for representing directory entries. LDAPv3 uses UTF-8 encoding standard for directory data encoding.

3. LDAP runs directly over TCP and can be used to access a standalone LDAP directory service or to access a X.500 directory service backend.

~ What does LDAP define ? ~

LDAP standard defines -

1. a network protocol for accessing information in the directory. It defines the operations one may perform e.g. search, add, delete, modify and change name. It also defines how operations and data are conveyed.

2. an information model defining the form and character of the information.

3. a namespace defining how information is referenced and organized.

4. an emerging distributed operation model defining how data may be distributed and referenced(v3).

~ Some basic LDAP concepts ~

Any directory sevice depends on "namespace", which provides for efficient referencing and retrieval of collections of related information. The namespace for LDAP is hierarchical, so it has the concept of fully qualified names called Distinguished Names (DN).

Accessing an LDAP directory is accomplished by using a combination of DN, filter, and scope. A base DN indicates where in the hierarchy to begin the search. A filter specifies attribute types, assertion values, and matching criteria. A scope indicates what to search : the base DN itself, one level below the base DN, the entire sub-tree rooted at the base DN.

LDAP does not specify how the directory service itself operates.

LDAP directory service works based on the client-server model. LDAP is a message oriented protocol. One or more LDAP servers contains the data making up the LDAP directory tree. An LDAP client connects to an LDAP server and asks it a question. The server responds with the answer, or with a pointer to where the client can get more information (typically another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory. This is an important feature called global directory service.

Java Naming and Directory Interface (JNDI) supports LDAPv3 features like - V3 referrals, modify DN, schema support extensible match, UTF-8 encoding etc.

JNDI provides an excellent object-oriented abstraction of directory and naming. Capabilities enabled by JNDI are - accessing directory, searching directory, looking up objects, browsing namespaces etc.

LDAP Data Interchange Format (LDIF) is a text based format for describing directory info. There are 2 different types of LDIF files - the first form describes a set of directory entries while the other type is a series of LDIF update statements that describes changes to be applied to directory entries.

As LDAP protocol is message based, it allows the client to issue multiple requests at once. A client would generate a unique message ID for each request hence allowing the protocol to handle concurrent requests.

LDAP has 9 basic protocol operations in 3 groups -

1. Interrogation Operations : search, compare.

2. Update Operations : add, delete, modify, modify DN(rename).

3. Autheticate and Control operations : bind, unbind, abandon.

LDAPv3 is designed to be extensible via 3 methods -

a. LDAP extended operations

b. LDAP controls

c. Simple Authentication and Security Layer (SASL)

LDAP uses a simplified version of the Basic Encoding Rules (BER) which is a set of rules for encoding various data types, such as integers and strings, in a system independent fashion. It also defines ways of combining these primitive data types into useful structures such as sets and sequences. The simplified BER that LDAP uses is referred as Lightweight BER (LBER).

LDAP defines 4 models to guide directory usage -

1. LDAP information model.

2. LDAP naming model.

3. LDAP functional model.

4. LDAP security model.

~ LDAP Models ~

1. LDAP information model.

This model defines the types of data and basic units of information we can store in our directory. It also describes the building blocks to create our directory. The basic unit of information in a directory is "entry", which is a collection of information about an object.

An entry is just a set of "attributes" which describes one particular aspect of the object.

Each attribute has a type and one or more values.

The type describes the kind of information in the attribute and value is the actual data.

Attribute types have an associated syntax, which describes the types of data that may be placed in attribute values of that type.

The rules for how attribute values of a particular syntax are compared are referred to as "matching rules".

Two types of attributes :

user - "normal", maybe modified by the users of the directory (with appropriate permissions)

operational - special type, either modify the operation of the directory server or reflect the operational status of the directory.

Any entry in the directory has a set of attribute types that are required and a set of attribute types that are allowed.

The collection of all information about required and allowed attributes are called the "directory schemas". This allows us to retain control and maintain order over types of information stored in our directory.

2. LDAP naming model.

LDAP naming model defines how we organize and refer to our data. It describes the types of structures we can build out of our individual building blocks. This model specifies that entries are arranged in an inverted tree structure much like the UNIX file system hierarchy.

In LDAP, Distinguished Names (DNs) are how we refer to entries.

In any entry's DN, the leftmost component is called the relative distinguished name (RDN).

3. LDAP functional model.

This model consists of a set of operations divided into 3 groups :

I. Interrogation Operations : search, compare

Search operation requires 8 parameters -

a. base object for the search expressed as DN

b. three types of scope : subtree indicating that we want to search the entire subtree, scope of one level indicating that we want to search only the immediate children,scope of base indicating that we want to limit our search to just the base object.

c. "derefAliases" - tells the server whether aliases should be dereferenced when performing a search.

d. size limit - tells the server that the client is interested in receiving only a certain number of entries. A size limit of 0 means that the client wants to recieve all matching entries.

e. time limit - tells the server the maximum time in seconds that it should spend trying to honor a search request.

f. "attrsOnly" parameter - boolean which tells the server to send only the attributes to the client when set.

g. search filter - this is an expression that describes the types of entries to be returned.

h. list of attributes to be returned for each matching entry.

II. Update Operations : add, delete, modify, modify DN(rename)

III. Autheticate and Control operations : bind, unbind, abandon

A client binds by providing a distinguished name and a set of credentials.

In addition to these, v3 of the LDAP protocol defines a framework for adding new operations to the protocol via LDAP extended operations.

4. LDAP security model.

The framework for protecting the LDAP directory information from unauthorized accesses.

~ LDAP APIs ~

Some LDAP APIs are - C API (SDK), Netscape's Java SDK(all LDAP v3 features), PerLDAP (toolkit to access LDAP directories), Sun's JNDI (supports LDAP, NIS+ and others), Microsoft's ADSI (active directory services interface).

~ References ~

1. Understanding and Deploying Ldap Directory Services (The MacMillan Network Architecture Series); by Tim Howes, Mark Smith, Gordon Good

2. Ldap : Programming Directory-Enabled Applications With Lightweight Directory Access Protocol (MacMillan Technology Series); by Tim Howes, Mark Smith

3. Netscape DevEdge Online on LDAP : http://developer.netscape.com/tech/directory/index.htm

4. University of Michigan LDAP site : http://www.umich.edu/~dirsvcs/ldap/

5. Triangulum Software whitepaper : http://www.triangulum.com/wpaper.html

6. More LDAP information : http://www.kingsmountain.com/ldapRoadmap.html

7. LDAP RFCs : http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networking/Protocols/LDAP__Lightweight_Directory_Access_Protocol_/RFCs /

8. Innosoft LDAP FAQs link : http://www.critical-angle.com/ldapworld/ldapfaq.html

9. OpenLDAP : http://www.OpenLDAP.org/

10. Jef Hodges' LDAP site : http://www.stanford.edu/~hodges/