原文：https://blog.csdn.net/cruise_h/article/details/51013597
https://blog.csdn.net/weixin_42813765/article/details/82315305
https://www.cnblogs.com/codestory/p/5512104.html
Spring Security与CAS结合使用的意义
web应用中一个登陆过程，其实就是完成认证与授权。
所谓认证，就是当用户试图进入系统，而系统发现用户没有登陆，就调转到登陆页面。
所谓授权,指用户认证通过之后对该用户赋权限，即该用户能够访问这个系统的哪些功能（即该用户能够访问这个系统的哪些url地址及按钮）
Cas它的功能就是进行用户名密码认证。如果spring security与cas集成，就相当于spring security自身的登录认证功能转移到cas框架上，然后spring security进行认证之后的授权。
CAS原理和协议
基础模式
基础模式SSO访问流程主要有以下步骤：
1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2. 定向认证：SSO客户端会重定向用户请求到SSO服务器。
3. 用户认证：用户身份认证。
4. 发放票据：SSO服务器会产生一个随机的Service Ticket。
5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
如上图：CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS Client 会分析HTTP请求中是否包含请求Service Ticket( ST上图中的Ticket) ，如果没有，则说明该用户是没有经过认证的；于是CAS Client 会重定向用户请求到 CAS Server（Step 2），并传递Service（要访问的目的资源地址）。 Step 3是用户认证过程，如果用户提供了正确的Credentials， CAS Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，并且重定向用户到Service 所在地址（附带刚才产生的Service Ticket ）, 并为客户端浏览器设置一个Ticket Granted Cookie（TGC）；CAS Client 在拿到Service和新产生的 Ticket过后，在Step 5和Step6中与CAS Server进行身份核实，以确保 Service Ticket 的合法性。
在该协议中，所有与CAS Server的交互均采用SSL协议，以确保ST和TGC的安全性。协议工作过程中会有两次重定向的过程。但是 CAS Client与CAS Server之间进行Ticket验证的过程对于用户是透明的（使用HttpsURLConnection）。
各服务首次访问：若用户没有登录过执行以下图全部流程。若以在其他服务中登录则执行到下图第二步
同服务第二次访问（因为之前已创建session,所以不会再去cas server）
CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到CAS Server的时候，CAS Server会主动获到这个TGC cookie，然后做下面的事情：
1) 如果User持有TGC且其还没失效，那么就走基础协议图的Step4，达到了 SSO 的效果；
2) 如果TGC失效，那么用户还是要重新认证 (走基础协议图的Step3)。
辅助说明
CAS的SSO实现方式可简化理解为：1个Cookie和N个Session。CAS Server创建cookie，在所有应用认证时使用，各应用通过创建各自的Session来标识用户是否已登录。
用户在一个应用验证通过后，以后用户在同一浏览器里访问此应用时，客户端应用中的过滤器会在session里读取到用户信息，所以就不会去CAS Server认证。如果在此浏览器里访问别的web应用时，客户端应用中的过滤器在session里读取不到用户信息，就会去CAS Server的login接口认证，但这时CAS Server会读取到浏览器传来的cookie（TGC），所以CAS Server不会要求用户去登录页面登录，只是会根据service参数生成一个Ticket，然后再和web应用做一个验证ticket的交互而已。
Session共享
可以通过Nginx+SpringSession实现Session共享，这样既可以同步Session信息，又能使其他应用不用再做首次认证
https://www.cnblogs.com/codestory/p/5512104.html
Cas登录过期时间
1、修改Cas Server的CASTGC过期时间
修改Cas Server下cas/WEB-INF/spring-configuration/ticketExpirationPolicies.xml（CASTGC的过期时间，单位为秒）
<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy"
p:maxTimeToLiveInSeconds="28800"
p:timeToKillInSeconds="1800"/>
2、修改Cas Client的Session过期时间
向Cas Client下WEB-INF/web.xml添加以下代码（Session过期时间，单位为分钟）：
<session-config>
<session-timeout>30</session-timeout>
</session-config>
CAS代理模式
该模式形式为用户访问App1，App1又依赖于App2来获取一些信息，如：User -->App1 -->App2 。
这种情况下，假设App2也是需要对User进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致User的IE窗口不停地闪动)，CAS引入了一种Proxy认证机制，即CAS Client可以代理用户去访问其它Web应用。
代理的前提是需要CAS Client拥有用户的身份信息(类似凭据)。之前我们提到的TGC是用户持有对自己身份信息的一种凭据，这里的PGT就是CAS Client端持有的对用户身份信息的一种凭据。凭借TGC，User可以免去输入密码以获取访问其它服务的Service Ticket，所以，这里凭借PGT，Web应用可以代理用户去实现后端的认证，而无需前端用户的参与。