Lightweight Directory Access Protocol (LDAP)

As a general mechanism of the IP-based network for retrieval of the directory information, LDAP is uniformly supported by all products (IP PBXs, multiservice modules, and universal messaging platforms, to name just a few) that require directory access.
Add a Note HereThe Lightweight Directory Access Protocol (LDAP) was designed by the IETF for accessing directories based on the X.500 data model and directory service. It is a less complex alternative to the Directory Access Protocol defined by the ITU-T for the same purpose. At the time of this writing, the third version of the LDAP specification RFC 2251 has been approved by the IETF as a Proposed Standard.
Add a Note HereBefore describing LDAP, we should review its foundation: the X.500 data model and directory service. The X.500 data model is hierarchical; the information in the directory is arranged in the form of a tree, called the directory information tree (DIT), where the vertices denote entries representing objects in the real world. An entry is composed of attributes, each with a type and one or more values. Normally, one of the attributes is special in the way it has to assume a unique value for each of the sibling entries (that is, those descending from the same vertex) in the DIT. As a result, the attribute and value pair, called the relative distinguished name (RDN), unambiguously distinguishes an entry from its siblings. The concatenation of the RDN of an entry and the RDNs of all its superior nodes (in descending order) further forms the distinguished name, which uniquely identifies the entry in the entire DIT.
Add a Note HereThe X.500 directory is a logical concept and is normally distributed across many directories in practice. According to ITU-T Recommendation X.500, the directory provides the directory service upon the requests of users. The requests, subject to security measures such as authentication and access control, are typically to interrogate or modify the directory entries. The directory always reports the outcome of a request, whether the operation succeeds or not. In particular, X.500 permits the directory to return a referral, which suggests an alternative access point where the user can make the request.
Add a Note HereIn support of the X.500 data model and directory service, LDAP is designed as a client-server protocol, which assumes a reliable connection-oriented underlying transport, such as Transmission Control Protocol/Internet Protocol (TCP/IP). A client sends a server a request describing the operation desired on the X.500 directory. The server performs the operation and then returns one or more responses indicating the results of the operation. RFC 2251 specifies the following LDAP requests:

§  Add a Note HereBindRequest. Starts an LDAP protocol session; allows authentication information to be exchanged between the client and server.
§  Add a Note HereUnbindRequest. Terminates an LDAP protocol session.
§  Add a Note HereSearchRequest. Requests a search based on specified criteria within the directory.
§  Add a Note HereAddRequest. Adds an entry into the directory.
§  Add a Note HereModifyRequest. Modifies an entry in the directory.
§  Add a Note HereDelRequest. Removes an entry from the directory.
§  Add a Note HereModifyDNRequest. Changes the leftmost component of the name of an entry or moves a subtree of entries to a new location in the directory.
§  Add a Note HereCompareRequest. Compares an assertion against the attributes of an entry in the directory.
§  Add a Note HereAbandonRequest. Abandons an outstanding operation.
Add a Note HereFor each of the preceding requests, a matching response is defined.
Add a Note HereA notable aspect of LDAP Version 3 is its support of operations defined elsewhere using a special request, ExtendedRequest, which serves as the envelope for foreign operations. The results of the operations are returned in the response to ExtendedRequest. This special request feature enables development of dynamic directory services, which are particularly relevant to services such as IP telephony and Internet call waiting. Dynamic directory services are concerned with the directory entries that exist only for a certain period of time. Such an entry is associated with a time-to-live, which is set upon creation and can be reset as needed. After being set or reset, the time-to-live decreases with each clock tick. When it reaches zero, the entry is removed. An example of dynamic entries is the description of an online user; naturally it exists only for as long as the user stays online. RFC 2598 defines an operation to be used within ExtendedRequest to refresh the time-to-live of a dynamic entry by a client, typically the creator of the entry. In addition, it defines the schema extensions required for representing dynamic entries.
Add a Note HereRFC 2251 defines the LDAP syntax in Abstract Syntax Notation One (ASN.1). In addition, it prescribes that ASN.1 Basic Encoding Rules (BER) be used to encode the protocol elements for transfer. Certain restrictions apply to avoid the high overhead associated with BER.

No comments:

Telecom Made Simple

Related Posts with Thumbnails