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

通常，比简单DN匹配越来越复杂的策略需要在目录里定位一个用户入口。 这可以使用LdapUserSearch 的一个示例，它可以提供认证者实现，比如让他们定位一个用户。 提供的实现是FilterBasedLdapUserSearch 。

在成功认证用户之后，LdapAuthenticationProvider 会调用配置好的LdapAuthoritiesPopulator bean，尝试读取用户的授权集合。 这个DefaultLdapAuthoritiesPopulator 是一个实现类，它将通过搜索目录读取授权，查找用户成员所在的组（典型的这会是目录中的groupOfNames 或groupOfUniqueNames 入口）。 查看这个类的Javadoc获得它如何工作的更多信息。

典型的配置方法，使用到像我们这在里讨论的这些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.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>
                

这里建立了一个提供器，访问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, GrantedAuthority[] authority);

    void mapUserToContext(UserDetails user, DirContextAdapter ctx);
}
                

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

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