CAS集中式认证服务(CAS )允许单个用户只需提供一次证书就可以访问多个APP应用程序。
具体的框架有OAuth2、Shiro等。
常规CAS1.0登录详细过程
流程解决：
(1-2)用户首次通过浏览器访问受保护的APP应用系统app1，APP应用系统app1发现访问请求中没有jsessionidorST(serviceticket )
每个受保护的APP应用程序系统都部署有CAS client，它在逻辑上独立于APP应用程序系统，在物理上与APP应用程序系统一起部署，并通过过滤器保护APP应用程序系统。 CAS client主要提供两大功能。
AuthenticationFilter :负责验证用户是否经过了认证
ticketvalidationfilter :负责验证ST的合法性
APP应用程序app1确定用户是否通过JSESSIONID or ST登录。 在判断JSESSIONID之后再判断ST。
)3)浏览器浏览器重定向到cas服务以获取ST；
)4-5) CAS service发现tgc(ticketgrantingcookie )不存在以空ortgc为密钥的会话，并返回浏览器登录表单；
(6)浏览器Browser向用户显示登录页面；
(7-8)用户输入用户名、密码等登录信息后，浏览器将登录信息发送到CAS服务器；
(9-11 ) cas服务基于用户注册信息进行验证，验证通过后，cas服务通过tgc(ticketgrantingcookie，TGT ) ticketgrantingticket 以TGC为密钥的TGT用于制作对值的SSO(single-signon )会话并缓存在CAS service中，最后基于TGT制作ST )服务票证； 最后，TGC和ST返回浏览器；
为了保证ST的安全性： ST是随机生成的，没有规律性。 然后，CAS规定ST只能生存一定的时间，然后CAS service将其禁用。 另外，CAS协议规定ST只能使用1次，无论ST验证是否成功，CAS service都可以从服务器端缓存中清除该ST，从而避免1个ST被使用2次。
为什么不能用TGC代替ST，即为什么还需要由TGT另外生成一个ST？
如果有TGC代替ST，为了穿越域，在步骤11重定向时必须将TGC作为URL的一部分代替ST。 这样，TGC就会直接暴露出来，而且TGC的有效期相对较长，攻击者就可以获取此TGC并将其资源检索到另一个受保护的APP应用程序系统。 此外，还可以记录此TGC并在浏览器中退出。 如果删除了TGC，但未禁用CAS service SSO session，请使用记录的TGC获得受保护APP应用程序的访问权限。 这也是将ST设定为只能使用一次的理由。
cas服务主要是密钥分发中心(KDC )，KDC包括：
as (认证服务) :基于用户的登录信息，进行登录操作，发行TGT
TGS (票据授权服务) :基于TGT发行ST
) 12 )浏览器收到TGC后，设置cookie，拿着ST再次请求APP应用系统app1；
因此，虽然TGT依赖TGC索引，但是TGC cookie通常在关闭or浏览器的浏览器时被删除，但是当TGC被删除时TGT也会丢失，因此为了节省CAS服务缓存，会丢失
) 13 )受保护的APP应用系统app1携带ST去CAS service验证ST的合理性；
在这里，cas客户端的TicketValidationFilter起作用
) 14 ) CAS service验证ST，返回验证结果，返回主体和相关属性(包括后面的JSESSIONID )；
) 15 ) APP应用系统app1在确认通过ST验证后，制作此次连接的session，在浏览器中设定cookie JSESSIONID；
在认证成功之后创建APP应用session的目的是，以后用户不需要为了访问该APP应用而重新登录，也不需要再次到CAS service进行认证。 另一方面，也需要在APP应用系统中构建APP应用session。 由于ST是CAS service重定向带来的，所以以后浏览器访问时没有ST，ST最多只能使用一次也受到限制。 因此，需要在浏览器和APP应用程序系统之间验证用户登录。 这是APP应用程序session及其JSESSIONID。
(16 )浏览器设置APP应用程序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认证基本原理