也可以使用 <ldap-server> 元素来创建嵌入式服务器，这对于测试和演示非常有用。在这种情况下，不用 url 属性就可以使用它：

<ldap-server root="dc=springframework,dc=org"/>

这里我们指定目录的根目录应该是 "dc=springframework,dc=org"，这是默认的。使用这种方式，命名空间解析器将创建一个嵌入式 Apache 目录服务器，并扫描类路径以查找任何 LDIF 文件，它将尝试将其加载到服务器中。可以使用 ldif 属性来自定义此行为，该属性定义要加载的 LDIF 资源：

<ldap-server ldif="classpath:users.ldif" />

这使得用 LDAP 启动和运行更加容易，因为与外部服务器一起工作会很不方便。它还将用户隔离为连接 Apache 目录服务器所需的复杂 bean 配置。使用普通的 bean，配置会更加混乱。你必须具有可供应用程序使用的必要 Apache 目录依赖项 jar。这些可以从 LDAP 示例应用程序中获得。

这是最常见的 LDAP 认证方案。

<ldap-authentication-provider user-dn-pattern="uid={0},ou=people"/>

这个简单的示例将通过在所提供的模式中替换用户登录名并尝试使用登录密码绑定作为该用户，从而获得用户的DN。如果所有用户都存储在目录中的单个节点之下，这是可以的。如果你希望配置 LDAP 搜索过滤器来定位用户，则可以使用以下内容：

<ldap-authentication-provider user-search-filter="(uid={0})"
	user-search-base="ou=people"/>

如果与上面的服务器定义一起使用，则这将使用 user-search-filter 属性的值作为过滤器在 DN ou=people,dc=springframework,dc=org 下执行搜索。同样，用户登录名替换过滤器名称中的参数，因此它将搜索一个具有 uid 属性等于用户名的条目。如果不提供 user-search-base，则从根执行搜索。

如何从 LDAP 目录中加载组的权限是由以下属性控制的。

因此，如果我们使用以下配置

<ldap-authentication-provider user-dn-pattern="uid={0},ou=people"
		group-search-base="ou=groups" />

并且被成功认证为用户 "ben"，随后的权限加载将在目录条目 ou=groups,dc=springframework,dc=org 下执行搜索，查找包含属性 uniqueMember 的条目，该属性具有值 uid=ben,ou=people,dc=springframework,dc=org。默认情况下，权限名称将具有前缀 ROLE_。可以使用 role-prefix 属性来更改此项。如果不需要任何前缀，请使用 role-prefix="none"。有关加载权限的更多详细信息，请参阅 DefaultLdapAuthoritiesPopulator 类的 Javadoc。

认证器还负责检索所需的用户属性。这是因为属性的权限可能取决于所使用的身份验证的类型。例如，如果绑定为用户，则可能需要使用用户自己的权限来读取它们。

目前有两种提供 Spring Security 的认证策略：

上面讨论的 bean 必须能够连接到服务器。它们都必须提供一个 SpringSecurityContextSource，这是 Spring LDAP 的 ContextSource 的扩展。除非你有特殊要求，否则通常将配置一个 DefaultSpringSecurityContextSource bean，该 bean 可以使用 LDAP 服务器的 URL 配置，也可以使用 "manager" 用户的用户名和密码配置，默认情况下，该用户名和密码将在绑定到服务器时使用（而不是匿名绑定）。有关的更多详细信息，请阅读此类的 Javadoc 和 Spring LDAP 的 AbstractContextSource。

通常需要比简单的 DN 匹配更复杂的策略来定位目录中的用户条目。这可以封装在 LdapUserSearch 实例中，该实例可以提供给验证器实现，例如，以允许它们定位用户。提供的实现是 FilterBasedLdapUserSearch.

在成功认证用户之后，LdapAuthenticationProvider 将尝试通过调用配置的 LdapAuthoritiesPopulator bean 为用户加载一组权限。DefaultLdapAuthoritiesPopulator 是一个实现，它将通过搜索用户所属的组的目录来加载权限（通常这些组是目录中的 groupOfNames 或 groupOfUniqueNames 条目）。请参阅 Javadoc 以了解该类的工作原理。

如果只希望使用 LDAP 进行身份验证，但是从差异源（例如数据库）加载权限，则可以提供此接口的自己的实现并注入该接口。

一个典型的配置，使用我们讨论过的一些 bean，可能是这样的：

<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.ldap.authentication.LdapAuthenticationProvider">
<constructor-arg>
<bean class="org.springframework.security.ldap.authentication.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.userdetails.DefaultLdapAuthoritiesPopulator">
	<constructor-arg ref="contextSource"/>
	<constructor-arg value="ou=groups"/>
	<property name="groupRoleAttribute" value="ou"/>
</bean>
</constructor-arg>
</bean>

这将建立一个提供访问 LDAP 服务器的提供者，使用 URL ldap://monkeymachine:389/dc=springframework,dc=org。认证将通过尝试与 DN uid=<user-login-name>,ou=people,dc=springframework,dc=org 绑定来执行。在成功的认证之后，角色将通过在 DN ou=groups,dc=springframework,dc=org 下使用默认过滤器 (member=<user’s-DN>) 进行搜索分配给用户。角色名称将取自每个匹配的 "ou" 属性。

要配置用户搜索对象，该对象使用过滤器 (uid=<user-login-name>) 代替 DN 模式（或者除此之外），你需要配置以下 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>

并通过设置 BindAuthenticator bean 的 userSearch 属性来使用它。然后，认证器将调用搜索对象，以在试图绑定此用户之前获取正确的用户 DN。

使用 LdapAuthenticationProvider 进行认证的净结果与使用标准 UserDetailsService 接口的普通 Spring Security 认证相同。创建并存储在返回的 Authentication 对象中的 UserDetails 对象。与使用 UserDetailsService 一样，一个常见的要求是能够自定义这个实现并添加额外的属性。当使用 LDAP 时，这些通常是来自用户条目的属性。 UserDetails 对象的创建由提供程序的 UserDetailsContextMapper 策略控制，该策略负责将用户对象映射到 LDAP 上下文数据以及从 LDAP 上下文数据映射到用户对象：

public interface UserDetailsContextMapper {

UserDetails mapUserFromContext(DirContextOperations ctx, String username,
		Collection<GrantedAuthority> authorities);

void mapUserToContext(UserDetails user, DirContextAdapter ctx);
}

只有第一个方法与认证相关。如果提供此接口的实现并将其注入 LdapAuthenticationProvider，则可以精确控制 UserDetails 对象的创建方式。第一个参数是 Spring LDAP 的 DirContextOperations 的实例，它允许你访问在认证期间加载的 LDAP 属性。username 参数是用于身份验证的名称，最后一个参数是由配置的 LdapAuthoritiesPopulator 为用户加载的权限集合。

加载上下文数据的方式略有不同，这取决于你使用的认证类型。使用 BindAuthenticator，从绑定操作返回的上下文将用于读取属性，否则将使用从配置的 ContextSource 获得的标准上下文读取数据（当搜索被配置为定位用户时，这将是搜索对象）。

配置 ActiveDirectoryLdapAuthenticationProvider 非常简单。你只需要提供域名和 LDAP URL 来提供服务器的地址 ^[20]。一个示例配置会是这样的：

<bean id="adAuthenticationProvider"
class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
	<constructor-arg value="mydomain.com" />
	<constructor-arg value="ldap://adserver.mydomain.com/" />
</bean>
}

注意，不需要指定单独的 ContextSource 来定义服务器位置 - bean 是完全自包含的。例如，名为 "Sharon" 的用户能够通过输入用户名 sharon 或完整的激活目录用户 userPrincipalName（即 sharon@mydomain.com）进行认证。然后将定位用户的目录条目，并返回属性以供定制创建的 UserDetails 对象时使用（如上所述，为此可以注入 UserDetailsContextMapper）。所有与目录的交互都发生在用户自身的身份上。没有 "manager" 用户的概念。

默认情况下，用户权限是从用户条目的 memberOf 属性值中获取的。分配给用户的权限可以再次使用 UserDetailsContextMapper 定制。还可以向提供程序实例中注入 GrantedAuthoritiesMapper，以控制最终在 Authentication 对象中的权限。