Comparison of the LDAP and JNDI Models

LDAP v3

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

Internationalization

Internationalization is addressed via an international character set (ISO 10646) to represent protocol elements that are strings (such as DNs). Version 3 also differs from version 2 in that it 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. SASL specifies a challenge-response protocol in which data is exchanged between the client and the server for the purposes of authentication.

Several SASL mechanisms are 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, provided that the LDAP v3 server supports them. Moreover, new (yet-to-be defined) SASL mechanisms can be used without changes to the LDAP having to be made.

Referrals

A referral is information that a server sends back to the client indicating that the requested information 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 of 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 such as the LDAP is useful for ensuring that all of the directory clients and servers "speak the same language." When many different directory client applications and directory servers are deployed in a network, it also is very useful for all of these entities to talk about the same objects. For example, if applications App1 and App2 both need to associate data with a user, then 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 things, the types of objects that a directory may have and the mandatory and optional attributes that each type of object may 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. It also defines a way for a client application to access the server's schema so that it can find out the types of objects and attributes that a particular server supports.

The LDAP v3 further 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 defines an "extended" operation. The "extended" operation takes a request as an 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

Another way to add new features is by using a control. The LDAP v3 allows the behavior of any operation to be modified through the use of controls. Any number of controls may be sent along with an operation, and any number of controls may 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 the "name" attribute.

Like extensions, such controls can be standard or proprietary.

Additional Differences

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 the client's 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 is the case of the LDAP v2). The client specifies the DN of the entry, the new RDN, and the (optional) DN of the new parent for the new RDN. If the optional DN of the new parent is not specified, then 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 those 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.

LDAP v3 Compared to 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 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