LDAP认证

这个<ldap-server>元素也可以用来创建一个嵌入服务器，这在测试和演示的时候特别有用。 在这种情况，你不需要使用url属性：

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

    

这里我们指定目录的根DIT应该是“dc=springframework,dc=org”，这是默认的。 使用这种方式，命名空间解析器会建立一个嵌入Apache目录服务器，然后检索classpath下的LDIF文件，尝试从它里边把数据加载到服务器里。 你可以通过ldif属性自定义这些行为，这样可以定义具体要加载哪个LDIF资源：

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

这就让启动和运行LDAP变得更轻松了，因为使用一个外部服务器还是不大方便。 它也避免链接到Apache目录服务器的复杂bean配置。 如果使用普通Spring 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"/>
                    

如果使用了上面的服务器定义，它会在DNou=people,dc=springframework,dc=org下执行搜索，使用user-search-filter里的值作为过滤条件。 然后把用户登录名作为过滤名称的一个参数。 如果没有提供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属性值为ou=groups,dc=springframework,dc=org的入口。 默认，权限名都要以ROLE_作为前缀。 你可以使用role-prefix属性修改它。 如果你不想使用任何前缀，可以使用role-prefix="none"。 要想得到更多读取权限的信息，可以查看DefaultLdapAuthoritiesPopulator类的Javadoc。

验证者还负责检索所有需要的用户属性。 这是因为对于属性的授权可能依赖于使用的验证类型 比如，如果对某个用户进行绑定，它也许必须通过用户自己的授权才能进行读取。

当前Spring Security提供两种验证策略：

上面讨论的bean必须连接到服务器。 它们都必须使用ContextSource，这个是Spring LDAP的一个扩展。 除非你有特定的需求，你通常只需要配置一个DefaultSpringSecurityContextSource bean，这个可以使用你的LDAP服务器的URL进行配置，可选项还有管理员用户的用户名和密码，这将默认用在绑定服务器的时候（而不是匿名绑定）。 参考Spring LDAP的AbstractContextSource类的Javadoc获得更多信息。

通常，比简单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> 
                

并使用它，设置认证者的userSearch属性。 这个认证者会调用搜索对象，在尝试绑定到用户之前获得正确的用户DN。

使用LdapAuthenticationProvider进行认证的结果，和使用普通Spring Security认证一样，都要使用标准UserDetailsService接口。 它会创建一个UserDetails对象，并保存到返回的Authentication对象里。 在使用UserDetailsService时，常见的需求是可以自定义这个实现，添加额外的属性。 在使用LDAP的时候，这些基本都来自用户入口的属性。 UserDetails对象的创建结果被提供者的UserDetailsContextMapper策略控制，它负责在用户对象和LDAP环境数据之间进行映射：

public interface UserDetailsContextMapper {
  UserDetails mapUserFromContext(DirContextOperations ctx, String username,
          Collection<GrantedAuthority> authority);

  void mapUserToContext(UserDetails user, DirContextAdapter ctx);
}
                

只有第一个方法与认证有关。 如果你提供这个接口的实现，你可以精确控制如何创建UserDetails对象。 第一个参数是Spring LDAP的DirContextOperations实例，他给你访问加载的LDAP属性的通道。 username参数是用来认证的名字，最后一个参数是从用户加载的授权列表。]

环境数据加载的方式不同，视乎你采用的认证方法。 使用BindAuthenticator，从绑定操作返回的环境会用来读取属性，否则数据会通过标准的环境，从配置好的ContextSource获得（当测试配置好定位用户，这会从搜索对象中获得数据）。