Comparison of the LDAP and JNDI Models |
The Internet community, recognizing the need for an X.500-like service but faced with different underlying network infrastructure (TCP/IP instead of OSI), designed a new protocol based on the X.500 DAP protocol, called Lightweight DAP, or LDAP. RFC 1777 defines what is now called version 2 of the LDAP (or LDAP v2).The goal of the LDAP v2 was a protocol that could be easily implemented, with special focus on being able to build small and simple clients. One way that it attempted to achieve simplification was to use a lot of strings and to minimize wherever possible the use of structures. DNs, for example, are represented in the protocol as strings, as are attribute type names and many attribute values.
The protocol consists of the client's sending requests to the server, to which the server responds, though not necessarily in the same order in which the requests were sent. Each request is tagged with an ID so that requests and responses can be matched. The protocol works over either TCP or UDP, although the TCP version is most commonly used.
Because of the focus on clients, the LDAP community also defined standards for the string representation of DNs (RFC 1779), search filters (RFC 1960), and attribute syntaxes (RFC 1778), for a C language-based API (RFC 1823), and for the format of URLs for accessing LDAP services (RFC 1959).
Operations
The following table lists the operations defined in the LDAP v2.
Operation Description bind Used to start a connection with the LDAP server. The LDAP is a connection-oriented protocol. The client specifies the protocol version and the client authentication information. unbind Used to terminate the connection with the LDAP server. search Used to search the directory. The client specifies the starting point (base object) of the search, the search scope (either the object only, its children, or the subtree rooted at the object), and a search filter (RFC 1960). It can also supply other information to control the search, such as the names of the attributes to return and the size and time limits. The search results consist of LDAP entries (and the attributes requested) that satisfy the filter. modify Used to modify an existing entry. The client specifies the name of the entry to be modified and a list of modifications. Each modification consists of an attribute and information regarding whether its values are to be added, deleted, or replaced. add Used to add a new entry. The client specifies the name of the new entry and a set of attributes for the new entry. delete Used to remove an existing entry. The client specifies the name of the entry to remove. modify RDN Used to change the RDN of the last component of an existing entry (that is, to assign the entry a new name in the same context). The client specifies the DN for the entry and the new RDN. compare Used to test whether an entry has an attribute/value pair. The client specifies the name of the entry and the name and value to check. abandon Used to terminate an outstanding request. LDAP v2 Compared to the X.500 Standard
At a very high level, the LDAP v2 looks a lot like the X.500. Both define a DIT consisting of entries having DNs. Each entry consists of a set of attributes. Both directories can be searched by using search filters that contain (at the structural level) more or less the same elements. The operations defined by both protocols (such as "search") are very similar.
Of course, many implementation differences exist between the X.500 and the LDAP. Most notably, their underlying protocol stacks are different. The X.500 protocols sit on top of the session/presentation layer of the OSI stack, whereas the LDAP runs on top of TCP. Furthermore, the X.500 standard is comprehensive, with details specified to maximize interoperability in client/server and server/server interactions. By contrast, the LDAP v2 standard, because of its goals, is much more minimal.
Comparison of the LDAP and JNDI Models |