The LDAP information model comes from X.500 and is based on the entry, which contains information about some object (e.g., a person). Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kinds of values are allowed in the attribute (e.g., ASCII characters, a jpeg photograph, etc.) and how those values behave during directory operations (e.g., is case significant during comparisons).
Entries may be organized in a tree structure, usually based on political, geographical, and organizational boundaries. Other structures are possible, including a flat namespace. Each entry is uniquely named relative to its sibling entries by its relative distinguished name (RDN) consisting of one or more distinguished attribute values from the entry. At most one value from each attribute may be used in the RDN. For example, the entry for the person Babs Jensen might be named with the "Barbara Jensen" value from the CN (commonName) attribute.
A globally unique name for an entry, called a distinguished name or DN, is constructed by concatenating the sequence of RDNs from the entry up to the root of the tree. For example, if Babs worked for the University of Michigan, the DN of her U-M entry might be "cn=Barbara Jensen,o=University of Michigan,c=US". The DN format used by LDAP is defined in RFC2253.
Operations are provided to authenticate, search for and retrieve information, modify information, and add and delete entries from the tree.
An LDAP server may return referrals if it cannot completely service a request (for example if the request specifies a directory base outside of the tree managed by the server). JLDAP offers the programmer three options: the programmer can catch these referrals as exceptions and explicitly issue new requests to the referred-to servers, the programmer can provide an object to establish a new connection to a referred-to server, or the programmer can let the library automatically follow the referrals. In the latter case, the programmer may also provide a reauthentication object, allowing automatic referrals to proceed with appropriate credentials. If no such object is provided, referrals are followed with anonymous credentials, and the protocol level of the original connection is used. If the original connection used a socket factory or TLS, the referral connection will use the same.
Before the client encodes and sends a string value to a server, the string values are converted from the Java 16-bit Unicode format to UTF-8 format, which is the standard string encoding for LDAPv3 servers. The integrity of double-byte and other non-ASCII character sets is fully preserved.
The LDAPConnection class also provides fields for storing settings that are specific to the LDAP session (such as limits on the number of results returned or timeout limits). An LDAPConnection object can be cloned, allowing objects to share a single network connection but use different settings (using LDAPConstraints or LDAPSearchConstraints).
A synchronous search conducted by an LDAPConnection object returns results in an LDAPSearchResults object, which can be enumerated to access the entries found. Each entry (represented by an LDAPEntry object) provides access to the attributes (represented by LDAPAttribute objects) returned for that entry. Each attribute can produce the values found as byte arrays or as Strings.
Messages retrieved from an LDAPResponseListener are result objects derived from LDAPResponse. Messages retrieved from an LDAPSearchListener are either result objects derived from LDAPResponse, search results, or search result references.
An asynchronous search conducted by an LDAPConnection object returns results via the getResponse method of the LDAPSearchListener returned by the search operation. The getResponse method typically returns an LDAPSearchResult object which has a getEntry method that returns the LDAPEntry that represents the search entry.
None of the ancillary asynchronous classes are intended to be instantiated by a client, so they lack public constructors.
There are both synchronous and asynchronous versions of the LDAP protocol operations in this API. Synchronous methods do not return until the operation has completed.
Asynchronous methods take a listener parameter (either LDAPResponseListener or LDAPSearchListener) and return a listener object which is used to enumerate the responses from the server. A loop is typically used to read from the listener object, which blocks until there is a response available, until the operation has completed.
An LDAPResponseListener may be shared between operations, for multiplexing the results. In this case, the object returned on one operation is passed in to one or more other operations, rather than passing in null.
For the asynchronous methods, exceptions are raised only for connection errors. LDAP result messages are converted into LDAPResponse objects which are to be checked by the client for errors and referrals, whereas the synchronous methods throw an LDAPException on result codes other than 0.
To facilitate user feedback during synchronous searches, intermediate search results can be obtained before the entire search operation is completed by specifying the number of entries to return at a time. Standard Java Enumerations are used to parse synchronous search results.
Errors result in the throwing of an LDAPException, with a specific error code and context-specific textual information available.
If null is passed as the value of an LDAPConstraints or LDAPSearchConstraints parameter to an operation, the default constraints are used for that operation.
If null is passed as the value of a DN to an operation it is treated as if it was the empty string.
The API doesn't distinguish between LDAP search continuation references and LDAP referrals, presenting a unified interface to the client for handling the two.
Implementations of the API MUST ensure that the LDAPConnection class is thread-safe. Other classes and methods MAY be thread-safe and the implementor MUST indicate which classes and methods are thread-safe.
© Copyright 2014-2020, OpenLDAP Foundation. Privacy Statement
$Id: 65f162f18f7288bb204526b5fe97f6b7b1798a1e $