CAS原理及使用
概念介绍：
CAS （Central Authentication Service）中央认证服务，CAS 是 耶鲁大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法。其包括两部分： CAS Server 和 CAS Client 。
CAS Server负责完成对用户的认证工作 ，会为用户签发两个重要的票据：登录票据（TGT）和服务票据（ST）来实现认证过程, CAS Server需要独立部署 。
CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。准确地来说，它以Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含服务票据（ST）（由 CAS Server发出用于标识目标服务）。CAS Client与各个应用服务一起部署。
由上可知，它符合SSO中的架构模式，如下：
User （多个）
Web 应用（多个CAS Client—与Web应用部署在一起）
SSO 认证中心（ 一个CAS Server—独立部署）
名词解析：
CAS的核心就是其票据Ticket，及其在Ticket之上的一系列处理操作。这里主要介绍CAS1.0（我们使用的）的几种票据。
TGT（Ticket Grangting Ticket）
TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，生成一个TGT对象，放入自己的缓存（Session）；同时，CAS生成cookie（叫TGC，个人理解，其实就是TGT的SessionId），写入浏览器。TGT对象的ID就是cookie的值，当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值（SessionId）为key查询缓存中有无TGT（Session），如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
TGC （Ticket-granting cookie）
上面提到，CAS-Server生成TGT放入自己的Session中，而TGC就是这个Session的唯一标识（SessionId），以Cookie形式放到浏览器端，是CAS Server用来明确用户身份的凭证。（如果你理解Session的存放原理的话就很好理解）
ST（ServiceTicket）
ST是CAS为用户签发的访问某一服务票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。
为了保证ST的安全性：ST 是基于随机生成的，没有规律性。而且，CAS规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。而且，CAS 协议规定ST只能使用一次，无论 Service Ticket 验证是否成功， Cas-Server 都会清除服务端缓存（MemoryCache）中的该 Ticket ，从而可以确保一个 Service Ticket 不被使用两次。
示例验证分析：
这里用一个终端，对两个cas_client的三次请求来说明CAS的认证全过程，主要是TGT、TGC、ST等票据的传递，以及如何实现的SSO。
如下图，其中cas.pie.com 为cas-server,z.pie.com,ams.pie.server为cas-client，前两次请求都是访问的z.pie.com，主要来说明TGT、TGC、ST等票据的作用；然后第三次请求访问的是ams.pie.com，主要来说明如何实现的SSO。
请求1
【第一步】终端第一次访问z.pie.com，AuthenticationFilter会截获此请求：
1、首先，检测本地Session没有缓存有用户信息；
2、然后，检测到请求信息中没有ST；
3、所以，z.pie.com将请求重定向到cas.pie.com，并传递 Service （验证成功后跳转的路径），例：【http://cas.pie.com/CAS/login?service=http://z.pie.com/security/security!index.action】
【第二步】终端第一次访问cas.pie.com：
1、cas.pie.com检测到请求信息中没有TGC，所以跳转到自己的登录页；
2、终端输入用户名、密码登录cas.pie.com，认证成功后，cas.pie.com会生成登录票据—TGT（集成了用户信息与ST），并随机生成一个服务票据—ST与CAS会话标识—TGC。TGT可以认为是Session，而TGC就是这标识这个Session存到Cookie中的SessionID；ST即，根据Service生成Ticket。
3、然后，cas.pie.com会将Ticket加在url 后面，然后将请求redirect 回客户web 应用，例如URL为【http://z.pie.com/security/security!index.action?ticket=ST-273200-E1RwDwDSIQKJbGt7OD7M-zrcas.pie.com】
【第三步】这时，终端携带ticket再次请求z.pie.com：
1、这时客户端的AuthenticationFilter看到ticket 参数后，会跳过，由其后面的TicketValidationFilter 处理；
2、TicketValidationFilter 会利用httpclient工具访问cas 服务的/serviceValidate 接口, 将ticket 、service 都传到此接口，由此接口验证ticket 的有效性，即向cas.pie.com验证ST的有效性。
3、TicketValidationFilter如果得到验证成功的消息，就会把用户信息写入web 应用的session里。至此为止，SSO 会话就建立起来了。
请求2
会话已经建立起来了，这时用户在同一浏览器里第二次访问此web 应用（z.pie.com）时，AuthenticationFilter会在session 里读取到用户信息，这就代表用户已成功登录，所以就不会去CAS 认证了。
请求3
【第一步】与请求1是完全一样的，如下：终端第一次访问ams.pie.com，AuthenticationFilter会截获此请求：
1、首先，检测本地Session没有缓存有用户信息；
2、然后，检测到请求信息中没有ST；
3、所以， ams.pie.com将请求重定向到cas.pie.com，并传递 Service （验证成功后跳转的路径）
【第二步】然后，终端第二次访问ams.pie.com：此时，请求中会带有上次生成的TGC，然后根据TGC（SessionID）去查找是否有对应的TGT（Session），如果有，代表此用户已成功登录过，所以此时用户不必再去登录页登录（SSO的体现），而cas.pie.com会直接用找到的TGT签发一个ST，然后重定向到ams.pie.com，剩下的如请求1中的
【第三步】就完全一样了。
CAS-Client应用：
上文中涉及到两个filter
AuthenticationFilter：
该过滤器负责用户的认证工作，必须启用它。在这里可以做一些session共享的存储。
TicketValidationFilter：
该过滤器负责对Ticket的校验工作，必须启用它
除了以上两个，还有一个常用filter
SingleSignOutFilter：
该过滤器用于实现单点登出功能，在这里可以做一下session共享的销毁处理。
Cas-Client就是要使用这些filter实现与Cas-Server的交互，
Spring web服务：
SpringBoot服务：
cas.server-url-prefix= cas-server
cas.server-login-url=cas-client/cas/login
cas.client-host-url= cas-client
cas.validation-type=CAS
@Configuration
@EnableCasClient
public class CasConfigure extends CasClientConfigurerAdapter {
@Override
public void configureAuthenticationFilter(FilterRegistrationBean authenticationFilter) {
super.configureAuthenticationFilter(authenticationFilter); authenticationFilter.getInitParameters().put("authenticationRedirectStrategyClass","com.patterncat.CustomAuthRedirectStrategy");
}
}