The namespace configuration options we've used above are simple to use and much more concise than using Spring beans explicitly. There are situations when you may need to know how to configure Spring Security LDAP directly in your application context. You may wish to customize the behaviour of some of the classes, for example. If you're happy using namespace configuration then you can skip this section and the next one.
The main LDAP provider class is
org.springframework.security.providers.ldap.LdapAuthenticationProvider
.
This bean doesn't actually do much itself but delegates the work to two other beans, an
LdapAuthenticator
and an
LdapAuthoritiesPopulator
which are responsible for authenticating the user and retrieving the user's set of
GrantedAuthority
s respectively.
The authenticator is also responsible for retrieving any required user attributes. This is because the permissions on the attributes may depend on the type of authentication being used. For example, if binding as the user, it may be necessary to read them with the user's own permissions.
There are currently two authentication strategies supplied with Spring Security:
Authentication directly to the LDAP server ("bind" authentication).
Password comparison, where the password supplied by the user is compared with the one stored in the repository. This can either be done by retrieving the value of the password attribute and checking it locally or by performing an LDAP "compare" operation, where the supplied password is passed to the server for comparison and the real password value is never retrieved.
Before it is possible to authenticate a user (by either strategy), the
distinguished name (DN) has to be obtained from the login name supplied to the
application. This can be done either by simple pattern-matching (by setting the
setUserDnPatterns
array property) or by setting the
userSearch
property. For the DN pattern-matching approach, a standard Java pattern format
is used, and the login name will be substituted for the parameter
{0}
. The pattern should be relative to the DN that the
configured
SpringSecurityContextSource
will bind to (see the section on
connecting to the LDAP server
for more information on this). For example, if you are using an LDAP server with
the URL
ldap://monkeymachine.co.uk/dc=springframework,dc=org
, and
have a pattern
uid={0},ou=greatapes
, then a login name of "gorilla" will map
to a DN
uid=gorilla,ou=greatapes,dc=springframework,dc=org
. Each
configured DN pattern will be tried in turn until a match is found. For
information on using a search, see the section on
search objects
below. A combination of the two approaches can also be used - the patterns will
be checked first and if no matching DN is found, the search will be used.
The class
org.springframework.security.providers.ldap.authenticator.BindAuthenticator
implements the bind authentication strategy. It simply attempts to bind as the
user.
The class
org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticator
implements the password comparison authentication strategy.
The beans discussed above have to be able to connect to the server. They both have
to be supplied with a
SpringSecurityContextSource
which is an extension of Spring LDAP's
ContextSource
. Unless you have special requirements,
you will usually configure a
DefaultSpringSecurityContextSource
bean, which can be configured with the URL of your LDAP server and optionally with
the username and password of a "manager" user which will be used by default when
binding to the server (instead of binding anonymously). For more information read
the Javadoc for this class and for Spring LDAP's
AbstractContextSource
.
Often more a more complicated strategy than simple DN-matching is required to
locate a user entry in the directory. This can be encapsulated in an
LdapUserSearch
instance which can be supplied to the authenticator implementations, for example, to
allow them to locate a user. The supplied implementation is
FilterBasedLdapUserSearch
.
This bean uses an LDAP filter to match the user object in the directory. The
process is explained in the Javadoc for the corresponding search method on the
JDK
DirContext class.
As explained there, the search filter can be supplied with parameters. For this class, the only valid parameter is
{0}
which will be replaced with the user's login name.
After authenticating the user successfully, the LdapAuthenticationProvider
will attempt to load a set of authorities for the user by calling the configured
LdapAuthoritiesPopulator
bean. The DefaultLdapAuthoritiesPopulator
is an implementation which will load the authorities by searching the directory for groups of which the user is a member
(typically these will be groupOfNames
or groupOfUniqueNames
entries in the directory).
Consult the Javadoc for this class for more details on how it works.
A typical configuration, using some of the beans we've discussed here, might look like this:
<bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource"> <constructor-arg value="ldap://monkeymachine:389/dc=springframework,dc=org"/> <property name="userDn" value="cn=manager,dc=springframework,dc=org"/> <property name="password" value="password"/> </bean> <bean id="ldapAuthProvider" class="org.springframework.security.providers.ldap.LdapAuthenticationProvider"> <constructor-arg> <bean class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator"> <constructor-arg ref="contextSource"/> <property name="userDnPatterns"> <list><value>uid={0},ou=people</value></list> </property> </bean> </constructor-arg> <constructor-arg> <bean class="org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator"> <constructor-arg ref="contextSource"/> <constructor-arg value="ou=groups"/> <property name="groupRoleAttribute" value="ou"/> </bean> </constructor-arg> </bean>
This would set up the provider to access an LDAP server with URL
ldap://monkeymachine:389/dc=springframework,dc=org
.
Authentication will be performed by attempting to bind with the DN
uid=<user-login-name>,ou=people,dc=springframework,dc=org
.
After successful authentication, roles will be assigned to the user by searching
under the DN
ou=groups,dc=springframework,dc=org
with the default filter
(member=<user's-DN>)
. The role name will be taken from the
“ou”
attribute of each match.
To configure a user search object, which uses the filter
(uid=<user-login-name>)
for use instead of the DN-pattern (or in addition to it), you would configure the
following bean
<bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch"> <constructor-arg index="0" value=""/> <constructor-arg index="1" value="(uid={0})"/> <constructor-arg index="2" ref="contextSource" /> </bean>
and use it by setting the BindAuthenticator
bean's
userSearch
property. The authenticator would then call the search object to obtain the correct
user's DN before attempting to bind as this user.
The net result of an authentication using LdapAuthenticationProvider
is the
same as a normal Spring Security authentication using the standard UserDetailsService
interface. A UserDetails
object is created and stored in the
returned Authentication
object. As with using a
UserDetailsService
, a common requirement is to be able to customize this
implementation and add extra properties. When using LDAP, these will normally be attributes from the user entry.
The creation of the UserDetails
object is controlled by the provider's
UserDetailsContextMapper
strategy, which is responsible for mapping user objects
to and from LDAP context data:
public interface UserDetailsContextMapper { UserDetails mapUserFromContext(DirContextOperations ctx, String username, GrantedAuthority[] authority); void mapUserToContext(UserDetails user, DirContextAdapter ctx); }
Only the first method is relevant for authentication. If you provide an implementation of this interface, you can
control exactly how the UserDetails object is created. The first parameter is an instance of Spring LDAP's
DirContextOperations
which gives you access to the LDAP attributes which were loaded.
The username
parameter is the name used to authenticate and the final parameter is the list of authorities
loaded for the user.
The way the context data is loaded varies slightly depending on the type of authentication you are using. With the
BindAuthenticatior
, the context returned from the bind operation will be used to read the attributes,
otherwise the data will be read using the standard context obtained from the configured
ContextSource
(when a search is configured to locate the user,
this will be the data returned by the search object).