/serviceValidate
（对应实现类 org.jasig.cas.web.ServiceValidateController ）
处理逻辑：
如果service 参数为空或ticket 参数为空，则转发到failureView （/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp ）
验证ticket 。以ticket 为参数，去缓存里找ServiceTicketImpl 对象，如果能找到，且没有过期，且ServiceTicketImpl 对象对应的service 属性和service 参数对应，则验证通过，验证通过后，请求转发至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），验证不通过，则转发到failureView 。
CAS CLIENT配置参数
CASFilter 参数说明
参数 是否必须 说明
com.olymtech.cas.client.filter.loginUrl 是 指定 CAS 提供登录页面的 URL
com.olymtech.cas.client.filter.validateUrl 是 指定 CAS 提供 service ticket 或 proxy ticket 验证服务的 URL
com.olymtech.cas.client.filter.serverName 是 指定客户端的域名和端口，是指客户端应用所在机器而不是 CAS Server 所在机器，该参数或 serviceUrl 至少有一个必须指定
com.olymtech.cas.client.filter.serviceUrl 否 该参数指定过后将覆盖 serverName 参数，成为登录成功过后重定向的目的地址
com.olymtech.cas.client.filter.wrapRequest 否 如果指定为 true，那么 CASFilter 将重新包装 HttpRequest,并且使 getRemoteUser() 方法返回当前登录用户的用户名
com.olymtech.cas.client.filter.noFilter 否 设置不过滤的路径，语法如下：/name1/,/name2,
com.olymtech.cas.client.filter.proxyCallbackUrl 否 用于当前应用需要作为其他服务的代理(proxy)时获取 Proxy Granting Ticket 的地址
com.olymtech.cas.client.filter.authorizedProxy 否 用于允许当前应用从代理处获取 proxy tickets，该参数接受以空格分隔开的多个 proxy URLs，但实际使用只需要一个成功即可。当指定该参数过后，需要修改 validateUrl 到 proxyValidate，而不再是 serviceValidate
com.olymtech.cas.client.filter.renew 否 如果指定为 true，那么受保护的资源每次被访问时均要求用户重新进行验证，而不管之前是否已经通过
com.olymtech.cas.client.filter.gateway 否 指定 gateway 属性
CAS安全性
CAS 的安全性从 v1 到 v3 ，都很依赖于 SSL ，所有与 CAS 的交互均采用 SSL 协议，确保，ST 和 TGC 的传输安全性。
TGC 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保CAS 的安全性。但 CAS 的传输安全性仅仅依赖于 SSL 。
TGC 面临的风险 主要并非传输窃取，而是存活周期内（ logout 前）被使用（如：离开了电脑）或窃取。
TGC 有自己的存活周期。可以在 web.xml 中，通过 grantingTimeout 来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，太长，会增加安全性风险。
ST 安全性
ST （ Service Ticket ）是通过 Http 传送的，网络中的其他人可以 Sniffer 到其他人的 Ticket 。CAS 协议从几个方面让 Service Ticket 变得更加安全：
1） ST 只能使用一次： CAS 协议规定，无论 ST 验证是否成功， CAS Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次；
2） ST 在一段时间内失效：假设用户拿到 ST 之后，他请求服务的过程又被中断了， ST 就被空置了，事实上，此时 TS 仍然有效。 CAS 规定 Service Ticket 只能存活一定的时间，然后 CAS Server 会让它失效。可通过在 web.xml 中配置参数，让 ST 在多少秒内失效。
3） ST 是基于随机数生成的。
实现单点登录的开发流程
通过上面的学习我们已经对单点登录以及CAS有了一定的了解，那么我们怎么入手搭建集群的单点登录呢?
步骤如下
搭建部署cas server
首先我们肯定是要下载cas server的代码，然后进行用户名密码验证认证方式的选型，选型结束后进行相应配置以及登录界面的修改等等。
然后把cas server的war包发布到服务器上，运行即可。
web项目中集成cas client
cas server搭建完成后登录认证模块已经有了，那么怎么跟我们的web项目关联起来呢? 这就需要在web 项目中集成cas的client客户端了，集成了之后，对cas client的配置文件进行配置，对应到cas server的地址，这样它们就能联系起来了。
cas server认证方式的选型
我们之前已经说过了cas支持很多种认证方式，我们即可把用户名密码写在xml中，然后cas来读取之后跟用户输入的帐号密码对比，也可以把用户名密码存在数据库中。
目前cas提供给了以下认证方式:
GENERIC
JAAS
JDBC--关系型数据库
MongoDB--非关系数据库
LDAP
LEGACY
RADIUS
SPNEGO
TRUSTED
X509
OAUTH
OPENID
在cas server的默认配置中，可以修改认证管理器中的认证处理器属性链表，增加或者修改相应的认证方式。
有些认证方式对于web开发，基本上不太好用或者不常用，因为他们的配置太不灵活或者太专业化。在此之所以列举了那么多关于cas的认证处理器，主要为了让大家知道，cas支持这种认证方式。比如现在新浪微博就对外开通了oauth认证接口，如果哪一天公司进行战略转形，希望用cas接新浪微博账号认证，那么就可以直接在此基础上进行好好研究。
一般LDAP和数据库比较常用，我们接下来会着重讲这两种的运用。 |
