Comparison of the LDAP and JNDI Models

LDAP Version 3

The LDAP version 3 (LDAP v3, RFC 2251) is an update of the version 2 protocol, designed to address some of the limitations of the LDAP v2 in the areas of internationalization, authentication, referral, and deployment. The LDAP v3 also allows new features to be added to the protocol in the future without changes to the protocol. This is done using extensions and controls.

Internationalization

Internationalization is addressed with the use of an internationalized character set (ISO 10646) to represent protocol elements that are strings (such as distinguished names). Another difference from version 2 is that version 3 uses UTF-8 to encode its strings.

Authentication

The LDAP v2 supported three types of authentication: anonymous, simple (clear-text password), and Kerberos V4.

The LDAP v3 uses the Simple Authentication and Security Layer (SASL) authentication framework (RFC 2222) to allow different authentication mechanisms to be used with the LDAP protocol. SASL specifies a challenge-response protocol in which data is exchanged between the client and the server for the purposes of authentication. There are several SASL mechanisms currently defined: DIGEST-MD5, CRAM-MD5, Anonymous, External, S/Key, GSSAPI, and Kerberos V4. An LDAP v3 client can use any of these SASL mechanisms as long as the LDAP v3 server supports them. Moreover, new (yet-to-be defined) SASL mechanisms can be used without changes to the LDAP protocol.

Referrals

A referral is information that a server sends back telling the client that the information it has requested can be found at another location (possibly at another server).

In the LDAP v2, servers are supposed to handle referrals and not return them to the client. This is because handling referrals can be very complicated and therefore would result in more complicated clients. As servers were built and deployed, referrals were found to be useful but not many servers supported server-side referral handling. So a way was found to retrofit the protocol to allow it to return referrals. This was done by placing the referral inside the error message of a "partial result" error response.

The LDAP v3 has explicit support for referrals and allows servers to return the referrals directly to the client.

Deployment

A common protocol like the LDAP is useful for ensuring that all the directory clients and servers "speak the same language." When many different directory client applications and directory servers are deployed in the network, it is also very useful for all these entities to talk about the same objects. For example, if applications App1 and App2 both need to associate data with a user, it makes sense for the directory to have a common notion of user that both applications can use rather than each going off and defining its own.

A directory schema specifies, among other rules, the types of objects that a directory can have and the mandatory and optional attributes that each type of object can have. The LDAP v3 defines a schema (RFC 2252 and RFC 2256) based on the X.500 standard for common objects found in the network, such as countries, localities, organizations, users/persons, groups, and devices. The LDAP v3 also defines a way for a client application to access the server's schema, so that the application can find out what sorts of objects and attributes a particular server supports.

The LDAP v3 also defines a set of syntaxes for representing attribute values (RFC 2252).

Extensions

In addition to the repertoire of predefined operations, such as "search" and "modify," the LDAP v3 protocol defines an extended operation. The extended operation takes a request as argument and returns a response. The request contains an identifier that identifies the request and the arguments of the request. The response contains the results of performing the request. The pair of extended operation request/response is called an extension. For example, there can be an extension for "Start TLS," which is a request for the client to the server to activate the "Start TLS" protocol. These extensions can be standard (defined by the LDAP community) or proprietary (defined by a particular directory vendor).

Controls

There is another way to add new features. The LDAP v3 allows the behavior of any operation to be modified through the use of controls. The protocol allows any number of controls to be sent along with an operation, and any number of controls to be returned with its results. For example, you can send a "sort" control along with a "search" operation that tells the server to sort the results of the search according to its "name" attribute. Like extensions, such controls can be standard or proprietary.

Other Differences from Version 2

Operation/Feature	Description
bind	The bind operation is optional and can be sent multiple times during a session. If a client requests an operation to be performed without doing an explicit bind, the client is treated as "anonymous." The client can also send a bind operation in the middle of a session to change his credentials (without sending an unbind first).
modify DN	The modify DN operation allows you to rename an entry to any other part of the namespace. (That is, you are not restricted to the same context, as was the case with the LDAP v2). The client specifies the (distinguished) name of the entry, the new RDN, and the (optional) distinguished name of the new parent for the new RDN. If the optional DN of the new parent is not specified, the parent of the original entry is used.
search filter	The LDAP v3 defines an updated search filter representation (RFC 2254) that supports the ISO 10646 character set, supports extensible matches, and uses the UTF-8 encoding.
operational attributes	Operational attributes are maintained by servers for administrative purposes. They are not visible to client applications unless the client applications explicitly ask for them. They are used to hold such information as time stamps and a subschema subentry (which is a pointer to schema information about the entry). The LDAP v3 defines these operational attributes and subschema entries and allows clients to access them.
LDAP URL	The LDAP v3 defines an updated LDAP URL format (RFC 2255) to support extensions.

Compared with The X.500 Standard

The LDAP v3 has many more features than the LDAP v2 and therefore departs from one of original goals of the LDAP v2, which was to have small and simple clients. The LDAP v3 supports a larger subset of the X.500 features than does the LDAP v2.

Comparison of the LDAP and JNDI Models