本文介绍了CAS中FastBindLdapAuthenticationHandler和BindLdapAuthenticationHandler的认证逻辑，以及如何根据场景选择合适的处理器。FastBind直接用用户名和密码查询LDAP，而Bind则通过管理员账号初始化查询。为了提升性能，文章提出了使用PoolingContextSource对ContextSource进行池化，并详细给出了配置示例。此外，还讨论了当LDAP仅存储电子邮件作为用户名时，如何通过PrincipalNameTransformer优化用户体验。
关于cas的ldap认证，可以参看
http://blog.163.com/magicc_love/blog/static/18585366220132294648822/
这篇文章对于如何配置ldap已介绍的算是比较全面了.
后面我主要描述一下这两个的认证逻辑.
org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler 认证逻辑是根据前台用户输入的
用户名与密码直接去查询是否有相应的用户存在，因为用户名/密码就是进入ldap服务器的通行证。所以在配置
ContextSource时可以不需要ldap服务器的管理员账号，但是它是每次认证都需要与ldap建立连接查询。
org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler 它的认证逻辑是根据前台用户输入的用户名（不包含密码）为条件，在ldap服务器
查询这个用户名的相关信息，返回一个集合，然后解析这个集合，逐个比对相应的密码如何匹配则认证成功，否则认证失败。在这个过程中，对于ContextSource的配置是需要ldap服务器的管理员账号，以满足初始查询。它的连接方式类似于数据库连接池。FastBindLdapAuthenticationHandler与BindLdapAuthenticationHandler
相比在性能方面，后者更占优势。但是当你应用第三方公司搭建的ldap服务器，而你又无法获取ldap服务器管理员的密码时，则FastBindLdapAuthenticationHandler就该上场了。
为了更好的提高性能，我们也可以将contextSource进行池化，当然这个也只能在BindLdapAuthenticationHandler应用，配置如下：
http://blog.163.com/magicc_love/blog/static/18585366220132294648822/
这篇文章对于如何配置ldap已介绍的算是比较全面了.
后面我主要描述一下这两个的认证逻辑.
org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler 认证逻辑是根据前台用户输入的
用户名与密码直接去查询是否有相应的用户存在，因为用户名/密码就是进入ldap服务器的通行证。所以在配置
ContextSource时可以不需要ldap服务器的管理员账号，但是它是每次认证都需要与ldap建立连接查询。
org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler 它的认证逻辑是根据前台用户输入的用户名（不包含密码）为条件，在ldap服务器
查询这个用户名的相关信息，返回一个集合，然后解析这个集合，逐个比对相应的密码如何匹配则认证成功，否则认证失败。在这个过程中，对于ContextSource的配置是需要ldap服务器的管理员账号，以满足初始查询。它的连接方式类似于数据库连接池。FastBindLdapAuthenticationHandler与BindLdapAuthenticationHandler
相比在性能方面，后者更占优势。但是当你应用第三方公司搭建的ldap服务器，而你又无法获取ldap服务器管理员的密码时，则FastBindLdapAuthenticationHandler就该上场了。
为了更好的提高性能，我们也可以将contextSource进行池化，当然这个也只能在BindLdapAuthenticationHandler应用，配置如下：
最低0.47元/天 解锁文章
7262
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
