Spring LDAP Reference

When no mapper is passed to a ldapTemplate.lookup(), the result is a DirContextAdapter instance. While the lookup method returns an Object, the lookupContext convenience method method automatically casts the return value to a DirContextOperations (the interface that DirContextAdapter implements).

Notice that we have duplicate code in the create and update methods. This code maps from a domain object to a context. It can be extracted to a separate method, as follows:

=== DirContextAdapter and Distinguished Names as Attribute Values

When managing security groups in LDAP, it is common to have attribute values that represent distinguished names. Since distinguished name equality differs from String equality (for example, whitespace and case differences are ignored in distinguished name equality), calculating attribute modifications using string equality does not work as expected.

For instance, if a member attribute has a value of cn=John Doe,ou=People and we call ctx.addAttributeValue("member", "CN=John Doe, OU=People"), the attribute is now considered to have two values, even though the strings actually represent the same distinguished name.

As of Spring LDAP 2.0, supplying javax.naming.Name instances to the attribute modification methods makes DirContextAdapter use distinguished name equality when calculating attribute modifications. If we modify the earlier example to be ctx.addAttributeValue("member", LdapUtils.newLdapName("CN=John Doe, OU=People")), it does not render a modification, as the following example shows:

In the preceding example, we implement BaseLdapNameAware to get the base LDAP path as described in [base-context-configuration]. This is necessary because distinguished names as member attribute values must always be absolute from the directory root.

=== A Complete PersonRepository Class

To illustrate the usefulness of Spring LDAP and DirContextAdapter, the following example shows a complete Person Repository implementation for LDAP:

== Object-Directory Mapping (ODM)

Object-relational mapping frameworks (such as Hibernate and JPA) offer developers the ability to use annotations to map relational database tables to Java objects. The Spring LDAP project offers a similar ability with respect to LDAP directories through a number of methods in LdapOperations:

=== Annotations

Entity classes managed with the object mapping methods are required to be annotated with annotations from the org.springframework.ldap.odm.annotations package. The available annotations are:

The @Entry and @Id annotations are required to be declared on managed classes. @Entry is used to specify which object classes the entity maps to and (optionally) the directory root of the LDAP entries represented by the class. All object classes for which fields are mapped are required to be declared. Note that, when creating new entries of the managed class, only the declared object classes are used.

In order for a directory entry to be considered a match to the managed entity, all object classes declared by the directory entry must be declared by the @Entry annotation. For example, assume that you have entries in your LDAP tree that have the following object classes: inetOrgPerson,organizationalPerson,person,top. If you are interested only in changing the attributes defined in the person object class, you can annotate your @Entry with @Entry(objectClasses = { "person", "top" }). However, if you want to manage attributes defined in the inetOrgPerson objectclass, you need to use the following: @Entry(objectClasses = { "inetOrgPerson", "organizationalPerson", "person", "top" }).

The @Id annotation is used to map the distinguished name of the entry to a field. The field must be an instance of javax.naming.Name.

The @Attribute annotation is used to map object class fields to entity fields. @Attribute is required to declare the name of the object class property to which the field maps and may optionally declare the syntax OID of the LDAP attribute, to guarantee exact matching. @Attribute also provides the type declaration, which lets you indicate whether the attribute is regarded as binary-based or string-based by the LDAP JNDI provider.

The @DnAttribute annotation is used to map object class fields to and from components in the distinguished name of an entry. Fields annotated with @DnAttribute are automatically populated with the appropriate value from the distinguished name when an entry is read from the directory tree. Only fields of type String can be annotated with @DnAttribute. Other types are not supported. If the index attribute of all @DnAttribute annotations in a class is specified, the DN can also be automatically calculated when creating and updating entries. For update scenarios, this also automatically takes care of moving entries in the tree if attributes that are part of the distinguished name have changed.

The @Transient annotation indicates that the field should be ignored by the object directory mapping and not mapped to an underlying LDAP property. Note that if a @DnAttribute is not to be bound to an Attribute. That is, it is only part of the Distinguished Name and not represented by an object attribute. It must also be annotated with @Transient.

=== Execution

When all components have been properly configured and annotated, the object mapping methods of LdapTemplate can be used as follows:

=== ODM and Distinguished Names as Attribute Values

Security groups in LDAP commonly contain a multi-value attribute, where each of the values is the distinguished name of a user in the system. The difficulties involved when handling these kinds of attributes are discussed in [dns-as-attribute-values].

ODM also has support for javax.naming.Name attribute values, making group modifications easy, as the following example shows:

When you modify group members by using setMembers, addMember, and removeMember and then calling ldapTemplate.update(), attribute modifications are calculated by using distinguished name equality, meaning that the text formatting of distinguished names is disregarded when figuring out whether they are equal.

== Advanced LDAP Queries

This section covers various how to use LDAP queries with Spring LDAP.

=== LDAP Query Builder Parameters

The LdapQueryBuilder and its associated classes are intended to support all of the parameters that can be supplied to an LDAP search. The following parameters are supported:

An LdapQueryBuilder is created with a call to the query method of LdapQueryBuilder. It is intended as a fluent builder API, where the base parameters are defined first, followed by the filter specification calls. Once filter conditions have been started to be defined with a call to the where method of LdapQueryBuilder, later attempts to call (for example) base are rejected. The base search parameters are optional, but at least one filter specification call is required. The following query searches for all entries with an object class of Person:

The following query searches for all entries with an object class of person and a cn (common name) of John Doe:

The following query searches for all entries with an object class of person and starting at a dc (domain component) of dc=261consulting,dc=com:

The following query returns the cn (common name) attribute for all entries with an object class of person and starting at a dc (domain component) of dc=261consulting,dc=com:

The following query uses or to search for multiple spellings of a common name (cn):

=== Filter Criteria

The earlier examples demonstrate simple equals conditions in LDAP filters. The LDAP query builder has support for the following criteria types:

=== Hardcoded Filters

There may be occasions when you want to specify a hardcoded filter as input to an LdapQuery. LdapQueryBuilder has two methods for this purpose:

You cannot mix the hardcoded filter methods with the where approach described earlier. It is either one or the other. If you specify a filter by using filter(), you get an exception if you try to call where afterwards.

== Configuration

The recommended way of configuring Spring LDAP is to use the custom XML configuration namespace. To make this available, you need to include the Spring LDAP namespace declaration in your bean file, as follows:

=== ContextSource Configuration

ContextSource is defined by using an <ldap:context-source> tag. The simplest possible context-source declaration requires you to specify a server URL, a username, and a password, as follows:

The preceding example creates an LdapContextSource with default values (see the table after this paragraph) and the URL and authentication credentials as specified. The configurable attributes on context-source are as follows (required attributes marked with *):

==== DirContext Authentication

When DirContext instances are created to be used for performing operations on an LDAP server, these contexts often need to be authenticated. Spring LDAP offers various options for configuring this.

By default, authenticated contexts are created for both read-only and read-write operations. You should specify the username and password of the LDAP user to be used for authentication on the context-source element.

Some LDAP server setups allow anonymous read-only access. If you want to use anonymous contexts for read-only operations, set the anonymous-read-only attribute to true.

===== Custom DirContext Authentication Processing

The default authentication mechanism used in Spring LDAP is SIMPLE authentication. This means that the principal (as specified by the username attribute) and the credentials (as specified by the password) are set in the Hashtable that is sent to the DirContext implementation constructor.

There are many occasions when this processing is not sufficient. For instance, LDAP Servers are commonly set up to accept communication only on a secure TLS channel. There might be a need to use the particular LDAP Proxy Auth mechanism or other concerns.

You can specify an alternative authentication mechanism by supplying a DirContextAuthenticationStrategy implementation reference to the context-source element. To do so, set the authentication-strategy-ref attribute.

====== TLS

Spring LDAP provides two different configuration options for LDAP servers that require TLS secure channel communication: DefaultTlsDirContextAuthenticationStrategy and ExternalTlsDirContextAuthenticationStrategy. Both implementations negotiate a TLS channel on the target connection, but they differ in the actual authentication mechanism. Where DefaultTlsDirContextAuthenticationStrategy applies SIMPLE authentication on the secure channel (by using the specified username and password), the ExternalTlsDirContextAuthenticationStrategy uses EXTERNAL SASL authentication, applying a client certificate that is configured by using system properties for authentication.

Since different LDAP server implementations respond differently to explicit shutdown of the TLS channel (some servers require the connection be shut down gracefully, while others do not support it), the TLS DirContextAuthenticationStrategy implementations support specifying the shutdown behavior by using the shutdownTlsGracefully parameter. If this property is set to false (the default), no explicit TLS shutdown happens. If it is true, Spring LDAP tries to shut down the TLS channel gracefully before closing the target context.

===== Custom Principal and Credentials Management

While the user name (that is, the user DN) and password used for creating an authenticated Context are statically defined by default (the ones defined in the context-source element configuration are used throughout the lifetime of the ContextSource), there are several cases where this is not the desired behavior. A common scenario is that the principal and credentials of the current user should be used when performing LDAP operations for that user. You can modify the default behavior by supplying a reference to an AuthenticationSource implementation to the context-source element by using the authentication-source-ref element, instead of explicitly specifying the username and password. The AuthenticationSource is queried by the ContextSource for principal and credentials each time an authenticated Context is to be created.

If you use Spring Security, you can make sure the principal and credentials of the currently logged-in user are used at all times by configuring your ContextSource with an instance of the SpringSecurityAuthenticationSource shipped with Spring Security. The following example shows how to do so:

==== Native Java LDAP Pooling

The internal Java LDAP provider provides some very basic pooling capabilities. You can turn this LDAP connection pooling on or off by using the pooled flag on AbstractContextSource. The default value is false (since release 1.3) — that is, the native Java LDAP pooling is turned off. The configuration of LDAP connection pooling is managed by using System properties, so you need to handle this manually, outside of the Spring Context configuration. You can find details of the native pooling configuration here.

==== Advanced ContextSource Configuration

This section covers more advanced ways to configure a ContextSource.

===== Custom DirContext Environment Properties

In some cases, you might want to specify additional environment setup properties, in addition to the ones directly configurable on context-source. You should set such properties in a Map and reference them in the base-env-props-ref attribute.

=== LdapTemplate Configuration

The LdapTemplate is defined by using a <ldap:ldap-template> element. The simplest possible ldap-template declaration is the element by itself:

The element by itself creates an LdapTemplate instance with the default ID, referencing the default ContextSource, which is expected to have an ID of contextSource (the default for the context-source element).

The following table describes the configurable attributes on ldap-template:

=== Obtaining a Reference to the Base LDAP Path

As described earlier, you can supply a base LDAP path to the ContextSource, specifying the root in the LDAP tree to which all operations are relative. This means that you are working only with relative distinguished names throughout your system, which is typically rather handy. There are, however, some cases in which you may need to have access to the base path in order to be able to construct full DNs, relative to the actual root of the LDAP tree. One example would be when working with LDAP groups (for example, the groupOfNames object class). In that case, each group member attribute value needs to be the full DN of the referenced member.

For that reason, Spring LDAP has a mechanism by which any Spring-controlled bean may be supplied with the base path on startup. For beans to be notified of the base path, two things need to be in place. First, the bean that wants the base path reference needs to implement the BaseLdapNameAware interface. Second, you need to define a BaseLdapPathBeanPostProcessor in the application context. The following example shows how to implement BaseLdapNameAware:

The following example shows how to define a BaseLdapPathBeanPostProcessor:

The default behavior of the BaseLdapPathBeanPostProcessor is to use the base path of the single defined BaseLdapPathSource (AbstractContextSource) in the ApplicationContext. If more than one BaseLdapPathSource is defined, you need to specify which one to use by setting the baseLdapPathSourceName property.

== Spring LDAP Repositories

Spring LDAP has built-in support for Spring Data repositories. The basic functionality and configuration is described here. When working with Spring LDAP repositories, you should remember the following:

=== QueryDSL support Basic QueryDSL support is included in Spring LDAP. This support includes the following:

== Pooling Support

Pooling LDAP connections helps mitigate the overhead of creating a new LDAP connection for each LDAP interaction. While Java LDAP pooling support exists, it is limited in its configuration options and features, such as connection validation and pool maintenance. Spring LDAP provides support for detailed pool configuration on a per-ContextSource basis.

Pooling support is provided by supplying a <ldap:pooling /> child element to the <ldap:context-source /> element in the application context configuration. Read-only and read-write DirContext objects are pooled separately (if anonymous-read-only is specified). Jakarta Commons-Pool is used to provide the underlying pool implementation.

=== DirContext Validation

Validation of pooled connections is the primary motivation for using a custom pooling library versus the JDK-provided LDAP pooling functionality. Validation allows pooled DirContext connections to be checked to ensure that they are still properly connected and configured when checking them out of the pool, checking them into the pool, or while they are idle in the pool.

If connection validation is configured, pooled connections are validated by using DefaultDirContextValidator. DefaultDirContextValidator does a DirContext.search(String, String, SearchControls), with an empty name, a filter of "objectclass=*", and SearchControls set to limit a single result with the only the objectclass attribute and a 500ms timeout. If the returned NamingEnumeration has results, the DirContext passes validation. If no results are returned or an exception is thrown, the DirContext fails validation. The default settings should work with no configuration changes on most LDAP servers and provide the fastest way to validate the DirContext. If you need customization, you can do so by using the validation configuration attributes, described in [pool-configuration].

=== Pool Configuration The following attributes are available on the <ldap:pooling /> element for configuration of the DirContext pool:

=== Pool2 Configuration

The following attributes are available on the <ldap:pooling2 /> element for configuring the DirContext pool:

=== Configuration

Configuring pooling requires adding an <ldap:pooling> element nested in the <ldap:context-source> element, as follows:

In a real-world situation, you would probably configure the pool options and enable connection validation. The preceding example demonstrates the general idea.

==== Validation Configuration

The following example tests each DirContext before it is passed to the client application and tests DirContext objects that have been sitting idle in the pool:

=== Known Issues

This section describes issues that sometimes arise when people use Spring LDAP. At present, it covers the following issues:

==== Custom Authentication

The PoolingContextSource assumes that all DirContext objects retrieved from ContextSource.getReadOnlyContext() have the same environment and, likewise, that all DirContext objects retrieved from ContextSource.getReadWriteContext() have the same environment. This means that wrapping an LdapContextSource configured with an AuthenticationSource in a PoolingContextSource does not function as expected. The pool would be populated by using the credentials of the first user, and, unless new connections were needed, subsequent context requests would not be filled for the user specified by the AuthenticationSource for the requesting thread.

== Adding Missing Overloaded API Methods

This section covers how to add your own overloaded API methods to implement new functionality.

=== Implementing Custom Search Methods

LdapTemplate contains several overloaded versions of the most common operations in DirContext. However, we have not provided an alternative for each and every method signature, mostly because there are so many of them. We have, however, provided a means to call whichever DirContext method you want and still get the benefits that LdapTemplate provides.

Suppose you want to call the following DirContext method:

There is no corresponding overloaded method in LdapTemplate. The way to solve this is to use a custom SearchExecutor implementation, as follows:

In your custom executor, you have access to a DirContext object, which you can use to call the method you want. You can then provide a handler that is responsible for mapping attributes and collecting the results. You can, for example, use one of the available implementations of CollectingNameClassPairCallbackHandler, which collects the mapped results in an internal list. In order to actually perform the search, you need to call the search method in LdapTemplate that takes an executor and a handler as arguments. Finally, you need to return whatever your handler has collected. The following example shows how to do all of that:

If you prefer the ContextMapper to the AttributesMapper, the following example shows what it would look like:

=== Implementing Other Custom Context Methods

In the same manner as for custom search methods, you can actually call any method in DirContext by using a ContextExecutor, as follows:

When implementing a custom ContextExecutor, you can choose between using the executeReadOnly() or the executeReadWrite() method. Suppose you want to call the following method:

The method is available in DirContext, but there is no matching method in LdapTemplate. It is a lookup method, so it should be read-only. We can implement it as follows:

In the same manner, you can perform a read-write operation by using the executeReadWrite() method.

== Processing the DirContext

This section covers how to process the DirContext, including pre- and post-processing.

=== Custom DirContext Pre- and Post-processing

In some situations, you might like to perform operations on the DirContext before and after the search operation. The interface that is used for this is called DirContextProcessor. The following listing shows the DirContextProcessor interface:

The LdapTemplate class has a search method that takes a DirContextProcessor, as follows:

Before the search operation, the preProcess method is called on the given DirContextProcessor instance. After the search has run and the resulting NamingEnumeration has been processed, the postProcess method is called. This lets you perform operations on the DirContext to be used in the search and to check the DirContext when the search has been performed. This can be very useful (for example, when handling request and response controls).

You can also use the following convenience methods when you do not need a custom SearchExecutor:

=== Implementing a Request Control DirContextProcessor

The LDAPv3 protocol uses “Controls” to send and receive additional data to affect the behavior of predefined operations. To simplify the implementation of a request control DirContextProcessor, Spring LDAP provides the AbstractRequestControlDirContextProcessor base class. This class handles the retrieval of the current request controls from the LdapContext, calls a template method for creating a request control, and adds it to the LdapContext. All you have to do in the subclass is to implement the template method called createRequestControl and the postProcess method for performing whatever you need to do after the search. The following listing shows the relevant signatures:

A typical DirContextProcessor is similar to the following example:

=== Paged Search Results

Some searches may return large numbers of results. When there is no easy way to filter out a smaller amount, it is convenient to have the server return only a certain number of results each time it is called. This is known as “paged search results”. Each “page” of the result could then be displayed, with links to the next and previous page. Without this functionality, the client must either manually limit the search result into pages or retrieve the whole result and then chop it into pages of suitable size. The former would be rather complicated, and the latter would consume unnecessary amounts of memory.

Some LDAP servers support PagedResultsControl, which requests that the results of a search operation are returned by the LDAP server in pages of a specified size. The user controls the rate at which the pages are returned, by controlling the rate at which the searches are called. However, you must keep track of a cookie between the calls. The server uses this cookie to keep track of where it left off the previous time it was called with a paged results request.

Spring LDAP provides support for paged results by using the concept for pre- and post-processing of an LdapContext, as discussed in the previous sections. It does so by using the PagedResultsDirContextProcessor class. The PagedResultsDirContextProcessor class creates a PagedResultsControl with the requested page size and adds it to the LdapContext. After the search, it gets the PagedResultsResponseControl and retrieves the paged results cookie, which is needed to keep the context between consecutive paged results requests.

The following example shows how the to use the paged search results functionality:

== Transaction Support

Programmers used to working with relational databases coming to the LDAP world often express surprise at the fact that there is no notion of transactions. It is not specified in the protocol, and no LDAP servers support it. Recognizing that this may be a major problem, Spring LDAP provides support for client-side, compensating transactions on LDAP resources.

LDAP transaction support is provided by ContextSourceTransactionManager, a PlatformTransactionManager implementation that manages Spring transaction support for LDAP operations. Along with its collaborators, it keeps track of the LDAP operations performed in a transaction, making a record of the state before each operation and taking steps to restore the initial state should the transaction need to be rolled back.

In addition to the actual transaction management, Spring LDAP transaction support also makes sure that the same DirContext instance is used throughout the same transaction. That is, the DirContext is not actually closed until the transaction is finished, allowing for more efficient resources usage.

=== Configuration

Configuring Spring LDAP transactions should look very familiar if you are used to configuring Spring transactions. You can annotate your transacted classes with @Transactional, create a TransactionManager instance, and include a <tx:annotation-driven> element in your bean configuration. The following example shows how to do so:

In a real-world situation, you would probably apply the transactions on the service-object level rather than the repository level. The preceding example demonstrates the general idea.

=== JDBC Transaction Integration

A common use case when working against LDAP is that some of the data is stored in the LDAP tree but other data is stored in a relational database. In this case, transaction support becomes even more important, since the update of the different resources should be synchronized.

While actual XA transactions is not supported, support is provided to conceptually wrap JDBC and LDAP access within the same transaction by supplying a data-source-ref attribute to the <ldap:transaction-manager> element. This creates a ContextSourceAndDataSourceTransactionManager, which then manages the two transactions virtually as if they were one. When performing a commit, the LDAP part of the operation is always performed first, letting both transactions be rolled back should the LDAP commit fail. The JDBC part of the transaction is managed exactly as in DataSourceTransactionManager, except that nested transactions are not supported. The following example shows an ldap:transaction-manager element with a data-source-ref attribute:

You can accomplish the same thing for Hibernate integration by supplying a session-factory-ref attribute to the <ldap:transaction-manager> element, as follows:

=== LDAP Compensating Transactions Explained

Spring LDAP manages compensating transactions by making a record of the state in the LDAP tree before each modifying operation (bind, unbind, rebind, modifyAttributes, and rename). This lets the system perform compensating operations should the transaction need to be rolled back.

In many cases, the compensating operation is pretty straightforward. For example, the compensating rollback operation for a bind operation is to unbind the entry. Other operations, however, require a different, more complicated approach because of some particular characteristics of LDAP databases. Specifically, it is not always possible to get the values of all Attributes of an entry, making the aforementioned strategy insufficient for (for example) an unbind operation.

This is why each modifying operation performed within a Spring LDAP managed transaction is internally split up into four distinct operations: a recording operation, a preparation operation, a commit operation, and a rollback operation. The following table describes each LDAP operation:

A more detailed description of the internal workings of the Spring LDAP transaction support is available in the Javadoc.

==== Renaming Strategies

As described in the table in the preceding section, the transaction management of some operations requires the original entry affected by the operation to be temporarily renamed before the actual modification can be made in the commit. The manner in which the temporary DN of the entry is calculated is managed by a TempEntryRenamingStrategy that is specified in a child element of the <ldap:transaction-manager > declaration in the configuration. Spring LDAP includes two implementations:

== User Authentication using Spring LDAP

This section covers user authentication with Spring LDAP. It contains the following topics:

=== Basic Authentication

While the core functionality of the ContextSource is to provide DirContext instances for use by LdapTemplate, you can also use it for authenticating users against an LDAP server. The getContext(principal, credentials) method of ContextSource does exactly that. It constructs a DirContext instance according to the ContextSource configuration and authenticates the context by using the supplied principal and credentials. A custom authenticate method could look like the following example:

The userDn supplied to the authenticate method needs to be the full DN of the user to authenticate (regardless of the base setting on the ContextSource). You typically need to perform an LDAP search based on (for example) the user name to get this DN. The following example shows how to do so:

There are some drawbacks to this approach. You are forced to concern yourself with the DN of the user, you can search only for the user’s uid, and the search always starts at the root of the tree (the empty path). A more flexible method would let you specify the search base, the search filter, and the credentials. Spring LDAP includes an authenticate method in LdapTemplate that provides this functionality: boolean authenticate(LdapQuery query, String password);.

When you use this method, authentication becomes as simple as follows:

=== Performing Operations on the Authenticated Context

Some authentication schemes and LDAP servers require some operation to be performed on the created DirContext instance for the actual authentication to occur. You should test and make sure how your server setup and authentication schemes behave. Failure to do so might result in users being admitted into your system regardless of the supplied DN and credentials. The following example shows a naïve implementation of an authenticate method where a hard-coded lookup operation is performed on the authenticated context:

It would be better if the operation could be provided as an implementation of a callback interface, rather than limiting the operation to always be a lookup. Spring LDAP includes the AuthenticatedLdapEntryContextMapper callback interface and a corresponding authenticate method: <T> T authenticate(LdapQuery query, String password, AuthenticatedLdapEntryContextMapper<T> mapper);

This method lets any operation be performed on the authenticated context, as follows:

=== Obsolete Authentication Methods

In addition to the authenticate methods described in the preceding sections, you can use a number of deprecated methods for authentication. While these work fine, we recommend using the LdapQuery methods instead.

=== Using Spring Security

While the approach described in the preceding sections may be sufficient for simple authentication scenarios, requirements in this area commonly expand rapidly. A multitude of aspects apply, including authentication, authorization, web integration, user context management, and others. If you suspect that the requirements might expand beyond just simple authentication, you should definitely consider using Spring Security for your security purposes instead. It is a full-featured, mature security framework that addresses the aforementioned aspects as well as several others.

== LDIF Parsing

LDAP Directory Interchange Format (LDIF) files are the standard medium for describing directory data in a flat-file format. The most common uses of this format include information transfer and archival. However, the standard also defines a way to describe modifications to stored data in a flat-file format. LDIFs of this later type are typically referred to as changetype or modify LDIFs.

The org.springframework.ldap.ldif package provides the classes needed to parse LDIF files and deserialize them into tangible objects. The LdifParser is the main class of the org.springframework.ldap.ldif package and is capable of parsing files that comply with RFC 2849. This class reads lines from a resource and assembles them into an LdapAttributes object.

=== Object Representation

Two classes in the org.springframework.ldap.core package provide the means to represent an LDIF in code:

LdapAttribute objects represent options as a Set<String>. The DN support added to the LdapAttributes object employs the javax.naming.ldap.LdapName class.

=== The Parser

The Parser interface provides the foundation for operation and employs three supporting policy definitions:

The default implementations of these interfaces are as follows:

Together, these four classes parse a resource line by line and translate the data into LdapAttributes objects.

The SeparatorPolicy determines how individual lines read from the source file should be interpreted, as the LDIF specification lets attributes span multiple lines. The default policy assesses lines in the context of the order in which they were read to determine the nature of the line in consideration. control attributes and changetype records are ignored.

The DefaultAttributeValidationPolicy uses REGEX expressions to ensure that each attribute conforms to a valid attribute format (according to RFC 2849) once parsed. If an attribute fails validation, an InvalidAttributeFormatException is logged, and the record is skipped (the parser returns null).

=== Schema Validation

A mechanism for validating parsed objects against a schema is available through the Specification interface in the org.springframework.ldap.schema package. The DefaultSchemaSpecification does not do any validation and is available for instances where records are known to be valid and need not be checked. This option saves the performance penalty that validation imposes. The BasicSchemaSpecification applies basic checks, such as ensuring DN and object class declarations have been provided. Currently, validation against an actual schema requires implementation of the Specification interface.

=== Spring Batch Integration

While the LdifParser can be employed by any application that requires parsing of LDIF files, Spring offers a batch processing framework that offers many file-processing utilities for parsing delimited files such as CSV. The org.springframework.ldap.ldif.batch package offers the classes needed to use the LdifParser as a valid configuration option in the Spring Batch framework. There are five classes in this package. Together, they offer three basic use cases:

The first use case is accomplished with LdifReader. This class extends Spring Batch’s AbstractItemCountingItemStreamItemReader and implements its ResourceAwareItemReaderItemStream. It fits naturally into the framework, and you can use it to read LdapAttributes objects from a file.

You can use MappingLdifReader to map LDIF objects directly to any POJO. This class requires you to provide an implementation of the RecordMapper interface. This implementation should implement the logic for mapping objects to POJOs.

You can implement RecordCallbackHandler and provide the implementation to either reader. You can use this handler to operate on skipped records. See the Spring Batch API documentation for more information.

The last member of this package, the LdifAggregator, can be used to write LDIF records to a file. This class invokes the toString() method of the LdapAttributes object.

== Utilities

This section describes additional utilities that you can use with Spring LDAP.

=== Incremental Retrieval of Multi-Valued Attributes

When there are a very large number of attribute values (>1500) for a specific attribute, Active Directory typically refuses to return all these values at once. Instead, the attribute values are returned according to the Incremental Retrieval of Multi-valued Properties method. Doing so requires the calling part to inspect the returned attribute for specific markers and, if necessary, make additional lookup requests until all values are found.

Spring LDAP’s org.springframework.ldap.core.support.DefaultIncrementalAttributesMapper helps when working with this kind of attributes, as follows:

The preceding example parses any returned attribute range markers and makes repeated requests as necessary until all values for all requested attributes have been retrieved.

== Testing

This section covers testing with Spring LDAP. It contains the following topics:

=== Using an Embedded Server

spring-ldap-test supplies an embedded LDAP server that is based on ApacheDS or UnboundID.

To get started, you need to include the spring-ldap-test dependency.

The following listing shows how to include the spring-ldap-test for Maven:

The following listing shows how to include the spring-ldap-test for Gradle:

=== ApacheDS

To use ApacheDS, you need to include a number of ApacheDS dependencies.

The following example shows how to include the ApacheDS dependencies for Maven:

The following example shows how to include the ApacheDS dependencies for Gradle:

The following bean definition creates an embedded LDAP server:

spring-ldap-test provides a mechanism to populate the LDAP server by using org.springframework.ldap.test.LdifPopulator. To use it, create a bean similar to the following:

Another way to work against an embedded LDAP server is by using org.springframework.ldap.test.TestContextSourceFactoryBean, as follows:

Also, org.springframework.ldap.test.LdapTestUtils provides methods to programmatically work with an embedded LDAP server.

=== UnboundID

To use UnboundID, you need to include an UnboundID dependency.

The following example shows how to include the UnboundID dependency for Maven:

The following example shows how to include the UnboundID dependency for Gradle:

The following bean definition creates an embedded LDAP server:

spring-ldap-test provides a way to populate the LDAP server by using org.springframework.ldap.test.unboundid.LdifPopulator. To use it, create a bean similar to the following:

Another way to work against an embedded LDAP server is by using org.springframework.ldap.test.unboundid.TestContextSourceFactoryBean. To use it, create a bean similar to the following:

Also, org.springframework.ldap.test.unboundid.LdapTestUtils provide methods to programmatically work with an embedded LDAP server.