The first thing you need to do is configure the server against which authentication
should take place. This is done using the
<ldap-server>
element from the security namespace. This can be configured to point at an external LDAP
server, using the
url
attribute:
<ldap-server url="ldap://springframework.org:389/dc=springframework,dc=org" />
The
<ldap-server>
element can also be used to create an embedded server, which can be very useful for
testing and demonstrations. In this case you use it without the
url
attribute:
<ldap-server root="dc=springframework,dc=org"/>
Here we've specified that the root DIT of the directory should be
“dc=springframework,dc=org”, which is the default. Used this way, the
namespace parser will create an embedded Apache Directory server and scan the
classpath for any LDIF files, which it will attempt to load into the server. You can
customize this behaviour using the
ldif
attribute, which defines an LDIF resource to be loaded:
<ldap-server ldif="classpath:users.ldif" />
This makes it a lot easier to get up and running with LDAP, since it can be inconvenient to work all the time with an external server. It also insulates the user from the complex bean configuration needed to wire up an Apache Directory server. Using plain Spring Beans the configuration would be much more cluttered. You must have the necessary Apache Directory dependency jars available for your application to use. These can be obtained from the LDAP sample application.
This is the most common LDAP authentication scenario.
<ldap-authentication-provider user-dn-pattern="uid={0},ou=people"/>
This simple example would obtain the DN for the user by substituting the user login name in the supplied pattern and attempting to bind as that user with the login password. This is OK if all your users are stored under a single node in the directory. If instead you wished to configure an LDAP search filter to locate the user, you could use the following:
<ldap-authentication-provider user-search-filter="(uid={0})" user-search-base="ou=people"/>
If used with the server definition above, this would perform a search under the DN
ou=people,dc=springframework,dc=org
using the value of the
user-search-filter
attribute as a filter. Again the user login name is substituted for the parameter in
the filter name. If
user-search-base
isn't supplied, the search will be performed from the root.
How authorities are loaded from groups in the LDAP directory is controlled by the following attributes.
group-search-base
. Defines the part of the directory
tree under which group searches should be performed.
group-role-attribute
. The attribute which contains
the name of the authority defined by the group entry. Defaults to
cn
group-search-filter
. The filter which is used to
search for group membership. The default is
uniqueMember={0}
, corresponding to the
groupOfUniqueMembers
LDAP class. In this case, the substituted parameter is the full
distinguished name of the user. The parameter
{1}
can be used if you want to filter on the login name.
So if we used the following configuration
<ldap-authentication-provider user-dn-pattern="uid={0},ou=people" group-search-base="ou=groups" />
and authenticated successfully as user
“ben”, the subsequent loading of authorities would perform a search
under the directory entry
ou=groups,dc=springframework,dc=org
, looking for entries which
contain the attribute
uniqueMember
with value uid=ben,ou=people,dc=springframework,dc=org
.
By default the authority names will have the prefix ROLE_
prepended. You can
change this using the role-prefix
attribute. If you don't want any prefix, use
role-prefix="none"
. For more information
on loading authorities, see the Javadoc for the
DefaultLdapAuthoritiesPopulator
class.