CAS
集中式认证服务(Central Authentication Service，CAS)，单点登录协议，允许一个用户访问多个应用程序，而只需要提供一次凭证。
具体实现框架有：OAuth2，Shiro等。
普通CAS1.0
登入详细流程
流程解析：
(1-2) 用户第一次通过浏览器Browser访问受保护的应用系统app1，应用系统app1发现访问请求中没有JSESSIONID or ST(service ticket) ，要求Browser重定向去CAS service获取ST；
在每个受保护的应用系统上都部署有CAS client，逻辑上与应用系统独立，物理上与应用系统部署在一起，实现上通过过滤器filter的方式保护应用系统，CAS client主要提供两大块功能：
AuthenticationFilter：负责校验用户是否已认证
TicketValidationFilter：负责校验ST的合法性
应用系统app1通过JSESSIONID or ST判断用户有没有登入：先判断JSESSIONID，再判断ST；
(3) 浏览器Browser重定向去CAS service获取ST；
(4-5) CAS service发现TGC(ticket granting cookie)为空 or 以TGC为key的session不存在，返回Browser登录表单；
(6) 浏览器Browser给用户展示登录页面；
(7-8) 用户输入用户名密码等登录信息后，Browser将登录信息送给CAS service；
(9-11) CAS service根据用户登录信息进行验证，如果验证通过，CAS service就会创建：TGC(ticket granting cookie)、TGT(ticket granting ticket，票根)，并将以TGC为key，TGT为value创建SSO(Single-SignOn) session缓存在CAS service，最后根据TGT创建ST(service ticket，票据)；最后TGC和ST返回给Browser；
为了保证ST的安全性：ST 是基于随机生成的，没有规律性。而且，CAS规定 ST 只能存活一定的时间，然后 CAS service 会让它失效。而且，CAS 协议规定ST只能使用一次，无论ST验证是否成功， CAS service 都会清除服务端缓存中的该ST ，从而可以确保一个ST不被使用两次。
为什么不能用TGC代替ST，即为什么还需要由TGT另外生成一个ST？
如果有TGC代替ST，为了跨域，在第11步重定向时势必要将TGC作为URL一部分代替ST，这样TGC直接暴露出来，且TGC有效期相对较长，攻击者完全可以取得这个TGC去另外受保护的应用系统获取资源，甚至于可以将这个TGC记录下来，在浏览器Browser退出，TGC删除但是CAS service SSO session未失效的情况下，拿着记录下来的TGC再去获取受保护应用系统的访问权限，这也是ST要设置只能使用一次的原因。
CAS service主要的是KDC(Key Distribution Center，密钥分发中心)，而KDC包括：
AS(Authentication Service，认证服务)：根据用户登入信息，进行登入操作，发放TGT
TGS(Ticket Granting Service，票据授受服务)：根据TGT，发放ST
(12) Browser收到TGC后设置cookie，并带着ST再次请求应用系统app1；
从这里看到，TGT是依靠TGC来索引的，而TGC cookie一般是指定时间or关闭浏览器Browser时删除，而一旦TGC删除，TGT也遗失了，因此，为节约CAS service缓存，可以定时删除迷失的TGT SSO session。
(13) 受保护的应用系统app1拿着ST去CAS service验证ST的合法性；
这里CAS client的TicketValidationFilter起作用
(14) CAS service验证ST，返回验证结果，认证主体和相关属性(包括后面的JSESSIONID)；
(15) 应用系统app1确认ST校验通过后，创建本次连接的session，并让Browser设置cookie JSESSIONID；
认证成功后创建应用session的目的是后面用户访问该应用无需再次登录及再次去CAS service中验证的必要，从另一方面来说，在应用系统上建立应用session也是必要的，因为ST是CAS service重定向带过来的，后面Browser访问时没有ST，也限制了ST最多只使用一次，因此必须有一个东西来在Browser和应用系统间证明用户的登入，这个东西就是应用session及其JSESSIONID。
(16) Browser设置应用系统app1本次连接访问的cookie JSESSIONID后，带着JSESSIONID cookie再去访问应用系统app1；
(17-18) 应用系统app1校验JSESSIONID通过，返回受保护的资源；
(19) 用户成功看到受保护的系统页面；
(20-21) 用户第二次访问受保护的应用系统app1时，Browser带着cookie JSESSIONID请求app1；
(22-23) 应用系统app1校验JSESSIONID通过，返回受保护的资源；
(24) 用户成功再次看到受保护的系统页面；
(25-27) 用户第一次访问受保护的应用系统app2时，应用系统app2发现访问请求中没有JSESSIONID or ST，要求Browser重定向去CAS service获取ST；
(28) 浏览器Browser带着cookie TGC重定向去CAS service获取ST；
(29-30) CAS service发现以TGC为key的session TGT存在，且TGT合法有效，则根据TGT创建ST，并将ST返回给Browser；
(31) Browser带着ST再次请求应用系统app2；
(32-34) 受保护的应用系统app2拿着ST去CAS service验证ST的合法性；CAS service验证ST，返回验证结果，认证主体和相关属性(包括后面的JSESSIONID)； 应用系统app1确认ST校验通过后，创建本次连接的session，并让Browser设置cookie JSESSIONID；
(35) Browser设置应用系统app2本次连接访问的cookie JSESSIONID后，带着JSESSIONID cookie再去访问应用系统app2；
(36-37) 应用系统app2校验JSESSIONID通过，返回受保护的资源；
(38) 用户成功看到受保护的系统页面；
CAS所有的请求都需要在有SSL保护的HTTS下进行才安全。
登出流程
代理CAS2.0
未完待续~~
参考：
如何设计一个通用的权限管理系统？说的太详细了！
cas系列(一)–cas单点登录基本原理
CAS单点登录原理（包含详细流程，讲得很透彻，耐心看下去一定能看明白！）
【SSO单点系列】（6）：CAS4.0 单点流程序列图（中文版）以及相关术语解释（TGT、ST、PGT、PT、PGTIOU）
CAS认证原理、TGT/ST、流程介绍
CAS-认证流程详解
Kerberos身份验证流程
kerberos 认证学习
kerberos的as tgs cs认证基本原理
