《Spring Security3》第十章（CAS）第一部分翻译（CAS基本配置）
第十章 使用中心认证服务（CAS）进行单点登录
在本章中，我们将会介绍使用中心认证服务（Central Authentication Service，CAS）为基于Spring Security的应用提供单点登录门户（single sign-on portal）。
在本章的内容中，我们将会：
l 学习CAS，包括它的架构以及对于系统管理员和各种规模组织的好处；
l 理解Spring Security怎样配置以处理认证请求拦截并重定向到CAS；
l 配置JBCP Pets应用以使用CAS的单点登录；
l 集成CAS和LDAP，并将数据通过CAS从LDAP传递到Spring Security；
l 了解CAS 2.0和SAML1.1的区别。
CAS简介
中心认证服务（Central Authentication Service，CAS）是一个开源的单点登录门户，提供了中心访问控制以及组织内基于web资源的认证。CAS对管理员的好处是很大的，它支持很多的应用和不同的用户社区：
l 个人或组对资源（应用）的访问可以配置到一个地方；
l 广泛支持各种认证存储（为了集中管理用户），这提供了单点认证和对广泛分布、跨机器环境的控制；
l 通过CAS客户端类库支持基于web和非基于web的Java应用的广泛支持；
l 只有一个地方有用户凭证信息（通过CAS），所以CAS的客户端应用不需要关于用户凭证信息的任何情况和如何验证它们。
我们本章主要关注的不是如何管理CAS，而重点是认证以及CAS怎样为我们的站点的用户提供认证。尽管CAS一般在企业或教育机构的intranet中见到，但是也能在一些面向公众的站点中见到如Sony Online Entertainment's 和Dun and Bradstreet's
CAS认证整体流程
CAS的基本认证流程包含以下的行为：
l 用户试图访问站点上的受保护资源；
l 站点的安全机制将用户重定向到CAS门户以要求用户提供凭证；
l CAS门户负责用户认证。如果CAS认证成功，用户被重定向会受保护的资源并带有分配给该请求的一个唯一CAS ticket；
l 站点的安全机制重新访问CAS服务器来校验这个ticket是否可接受（合法且没有过期等等）。CAS服务器返回一个assertion来标识已经建立起了信任关系。如果ticket被接受的话，信任已经建立，根据通常的授权检查用户可能已经可以进行下一步的操作。
直观起见，以上的过程在下面的图中进行了阐述：
从上面可以看到CAS服务器和受保护应用的整体交互，在用户信任之前要进行几次的数据交换握手。这种单点登录协议的复杂性使得很难通过常用的技术进行破解（考虑一下其它网络安全技术的预防措施，如使用SSL或网络监控）。
既然我们已经了解了CAS认证整体上如何工作，那看一下它怎样应用于Spring Security。
Spring与CAS
Spring Security拥有与CAS集成的强大功能，尽管没有像我们前面介绍OpenID和LDAP那样集成到security命名空间风格的配置中。作为替代，很多的配置依赖于bean织入和security命名空间中引用配置的bean声明。
基本的CAS认证涉及到以下两点：
l 替换标准的AuthenticationEntryPoint——它一般处理未认证用户重定向到登录页面——为将用户定向到CAS门户的实现；
l 当用户从CAS门户重定向回受保护资源时，处理分配的ticket，这通过使用一个自定义的过滤器实现。
关于CAS有一个很重要的事情要理解，在典型的部署环境中，CAS原来替换应用中所有的登录机制。这样，一旦为Spring Security配置了CAS，你的用户必须只能使用CAS作为你应用的认证机制。在大多数场景下，这不是什么问题，正如我们在前面讨论的，CAS设计用来代理认证请求到一个或多个的认证存储（类似于Spring Security委托给数据库或LDAP认证那样）。我们在这个图中可以看到，我们的应用不再检查认证存储以校验用户（尽管还需要一个数据源用来完整填充认证用户的UserDetails对象）。
当我们完成CAS与Spring Security集成的基本配置，我们可以从首页中移除“Log In”链接，当我们访问受限资源时会自动重定向到CAS的登录界面。当然，取决于应用，也可以允许用户明确进行登录（这样他们可以看到自定义的内容等等。）
CAS的安装和配置
CAS的好处是它背后有一个专业的团队不仅开发优秀的软件还提供精确完整的使用文档。如果你愿意练习本章的例子，我们建议你阅读CAS系统的“Get Started”手册。我们假设你在本章中将CAS部署到以下的位置：http://localhost:8080/cas/
在本章中，我们建议将CAS和JBCP Pets运行在两个不同的Tomcat实例中。这会使得你在修改JBCP Pets代码时，保持CAS正常运行。我们建议你配置CAS服务器在8080端口，JBCP Pets服务器在8081端口——我们在本章的例子是这样的配置。另外，本章中的例子用的是CAS服务器的最新版本，在写本书的时候为3.3.5。
【要注意的是，在CAS的3.x版本中对于一些后台的类做了很大的修改，所以如果你使用更在版本的CAS服务器，这些指令在你的环境下会有或多或少的不同。】
让我们继续并配置CAS认证所需要的组件。
基本的CAS集成配置
以下的图表说明了要将CAS认证集成到JBCP Pets应用中所要配置的Spring Security组件之间的关系。这应该会帮助你在后面配置bean时，对此有整体的认识。
添加CasAuthenticationEntryPoint
你可能会记得在第六章：高级配置与扩展中，AuthenticationEntryPoint的实现类用来将授权失败相关的异常转换成正确的行为——例如将未认证的用户重定向到登录页或者给用户展现出缺乏相应权限的出错页。从整体结构图中，我们可以看到有一个对用户访问受保护资源的拦截器，它将用户重定向到CAS门户页面——这是通过使用专门用来处理这个问题的o.s.s.cas.web.CasAuthenticationEntryPoint来完成的。
我们在dogstore-base.xml中配置这个支持bean的行为，如下：
<bean id="casAuthEntryPoint" class="org.springframework.security.cas.web.CasAuthenticationEntryPoint"> <property name="loginUrl" value="http://localhost:8080/cas/"/> <property name="serviceProperties" ref="casService"/> </bean>
紧接着，在dogstore-security.xml文件的security命名空间配置中添加对这个bean的引用：
<http auto-config="true" … entry-point-ref="casAuthEntryPoint">
最后，我们需要声明在CasAuthenticationEntryPoint中的serviceProperties引用，它是一个o.s.s.cas.ServiceProperties对象，声明了服务（应用）的属性（代表了我们的应用）。根据CAS认证过滤器的定义，我们声明的URL如下：
<bean id="casService" class="org.springframework.security.cas.ServiceProperties"> <property name="service" value="http://localhost:8081/JBCPPets/j_spring_cas_security_check"/> </bean>
我们可以看到ServiceProperties对象在不同的CAS组件间交换数据中扮演了重要角色——它被用作数据对象，来存储Spring CAS不同参与者共享（同时相匹配）的CAS配置。
【CAS将要认证访问的资源成为服务。服务以唯一的URL来进行标识。在CAS的管理界面上，服务能够被CAS管理员进行定义和配置。】
译者注：此处所谓的服务，指的就是各个使用CAS进行认证的应用。
其中service属性告知CAS，要对那个服务进行用户认证。回忆一下，CAS允许基于配置针对每个用户、每个应用进行有选择的授权。我们稍后配置处理该URL的过滤器时，还会介绍这个特殊URL。
如果你此时重新启动应用并试图访问受保护的资源，你将会立即被重定向到CAS门户进行认证。在我们应用中的一个受保护页面的例子是“My Account”页面——它要求用户被授予了ROLE_USER权限。CAS的默认设置允许认证任何用户名和密码相同的用户，你可以使用用户名admin和密码admin（或guest/guest）登录。
但是，你会发现，即使在登录后，你也会被立即再次重定向到CAS门户上。这是因为，尽管目标应用能够收到ticket，但是它不能校验它，所以CAS会处理AccessDeniedException异常并认为拒绝该ticket。
启用CAS票据校验
从前面“基本的CAS集成配置”一节的图中 我们可以看到，Spring Security借助FilterSecurityInterceptor来负责识别未认证的请求并将用户重定向到CAS。添加的CasAuthenticationEntryPoint重写了重定向到登录页的标准功能，并提供了从应用到CAS服务器的重定向。现在我们需要配置其它的东西，一旦经过了CAS的认证，用户应该在应用中也获得正确认证。
我们记得在第八章：对OpenID开放中讲到使用了类似的重定向方法，即将未认证的用户重定向到OpenID提供者上进行认证，并在校验凭证后重新返回到应用中。CAS与OpenID的区别在于，基于用户请求返回到应用中时（译者注：即在CAS上登录成功后），应用要请求CAS服务器来明确校验提供的凭证是合法准确的。而OpenID使用的是基于时间的nonce和共享的基于key的签名，所以OpenID提供者传回的凭证信息能够被独立进行校验。（译者注：即OpenID和CAS在各自认证成功后都会通知应用，但CAS还需要应用与其进行交互以校验ticket的正确性，而使用OpenID的应用不需要在于OpenID提供者进行交互）。
CAS方式的好处在于CAS服务器传递回来的认证用户信息很简单——只是简单的从CAS服务器返回给应用的一个URL参数。另外，应用本身并不需要跟踪和校验ticket，相反可以完全依赖CAS校验这个信息。与我们在OpenID中看到的很类似，一个过滤器负责识别CAS的重定向并将其视为认证请求。我们先在dogstore-base.xml中，配置这个过滤器为一个Spring bean，如下：
<bean id="casAuthenticationFilter" class="org.springframework.security.cas.web.CasAuthenticationFilter"> <property name="authenticationManager" ref="authenticationManager"/> </bean>
接下来，我们需要在dogstore-security.xml文件的security命名空间配置中，添加我们的自定义过滤器：
<http auto-config="true" ...>
...
<custom-filter ref="casAuthenticationFilter" position="CAS_FILTER"/>
</http>
最后，我们需要声明一个CasAuthenticationFilter需要的AuthenticationManager——这是通过在dogstore-security.xml中添加（如果还没有存在的话）<authentication-manager>元素的alias属性做到的：
<authentication-manager alias="authenticationManager">
你可能已经发现在配置ServiceProperties对象时，我们将CAS服务名字定义为如下的URL：http://localhost:8081/JBCPPets/j_spring_cas_security_check。正如我们在其它认证过滤器中所见过的那样，/j_spring_cas_security_check URL表明的是CasAuthenticationFilter认识的URL签名，专门用于CAS服务器的重定向响应。
【修改CAS服务URL。你可能希望修改默认的CAS服务URL /j_spring_cas_security_check——这能通过设置CasAuthenticationFilter的filterProcessesUrl属性为任意的相对URL。在有些时候修改默认的URL会有利于掩盖你的应用使用了Spring Security和/或CAS——尽管这种安全掩盖的并不能保证万无一失，但是能够预防一些针对公众站点的攻击。】
CasAuthenticationFilter用一些特定的凭证填充Authentication（一个UsernamePasswordAuthenticationToken）供下一个也即CAS最小化配置的最后一个元素识别。
使用CasAuthenticationProvider证明可靠性
如果你跟随本书了解Spring Security的逻辑流程，希望你会知道接下来是什么——Authentication token必须要用合适的AuthenticationProvider进行检验。CAS也不例外，所以最后的问题在于配置o.s.s.cas.authentication.CasAuthenticationProvider到AuthenticationManager中。
首先，我们需要在dogstore-base.xml中声明一个Spring bean，如下：
<bean id="casAuthenticationProvider" class="org.springframework.security.cas.authentication.CasAuthenticationProvider"> <property name="ticketValidator" ref="casTicketValidator"/> <property name="serviceProperties" ref="casService"/> <property name="key" value="jbcp-pets-dogstore-cas"/> <property name="authenticationUserDetailsService" ref="authenticationUserDetailsService"/> </bean>
接下来，我们要在dogstore-security.xml中配置对新AuthenticationProvider的引用，位于<authentication-manager>声明中：
<authentication-manager alias="authenticationManager"> <authentication-provider ref="casAuthenticationProvider"/> </authentication-manager>
如果你在还有前面练习的其它AuthenticationProvider，在于CAS共同使用时，记住将它们移走。现在，我们需要处理CasAuthenticationProvider中的其它属性和bean引用。
属性ticketValidator引用了接口org.jasig.cas.client.validation.TicketValidator的实现——因为我们使用的是CAS 2.0认证，我们要声明一个org.jasig.cas.client.validation.Cas20ServiceTicketValidator的实例，如下：
<bean id="casTicketValidator" class="org.jasig.cas.client.validation.Cas20ServiceTicketValidator"> <constructor-arg value="http://localhost:8080/cas/"/> </bean>
这个类的构造参数要（再一次）引用访问CAS服务器的URL。在这里你会注意到，我们已经离开了org.springframework.security包而到了org.jasig包中，这是CAS客户端JAR文件的一部分。我们稍后会看到TicketValidator接口拥有支持其它CAS认证的实现（还是在CAS客户端JAR文件中），如SAML认证。
【外部URL和独立环境的设置。如果你使用CAS配置真正的应用，在这里你可能会想到在Spring配置文件中写URL不是一个好主意。一般来说，对URL的存储和统一引用会抽取到单独的properties文件中，通过Spring PropertyPlaceholderConfigurer的占位符使用。这可以通过外部的properties文件重新设置特定环境的配置而不用关心Spring配置文件，这通常被认为是好的方式。】
接下来，看key属性——它用来校验UsernamePasswordAuthenticationToken的完整性，因为后者是可能随意定义的（译者注：即恶意用户仿造的）。
最后，authenticationUserDetailsService属性引用了一个o.s.s.core.userdetails.AuthenticationUserDetailsService对象，而它是用来将Authentication提供的用户名信息转换成完整的UserDetails。显然，这项技术只有在我们确认了Authentication的完整性后才会用到。我们配置这个对象引用了UserDetailsService 的实现JdbcDaoImpl。
<bean id="authenticationUserDetailsService" class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper"> <property name="userDetailsService" ref="jdbcUserService"/> </bean>
你可能会问，为什么不直接引用UserDetailsService——这是因为还有更高级的配置选项，它允许用CAS服务器返回的细节信息填充UserDetails对象。
到此时，我们可以完成并通过CAS进行登录并重定向回JBCP Pets应用。干得好！
