最近进一步学习和研究了单点登录的cas的运行机制，上一篇博客只是从很浅显的层面介绍过单点登录，这篇是小编对CAS有了又一次深入的研究后的总结；
CAS的包括两部分：CAS Server和CAS Client。
CAS Server 负责完成对用户的认证工作，需要独立部署，CAS Server会处理用户名/密码等凭证（Credentials）。
CAS Client负责处理对客户端保护资源的访问请求，需要对请求方进行身份认证时，重定向到CAS Server进行认证。CAS Client与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。
基础模式访问流程：
1、访问服务：SSO客户端发送请求访问应用系统提供的服务资源。
2、定向认证：SSO客户端会重定向到用户请求到的SSO服务器。
3、用户认证：用户身份认证。
4、发放发票：SSO服务器会产生一个随机的Service Ticket。
5、验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后，允许客户端访问服务。
6、传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。
在这个过程中，所有与CAS Server的交互均采用SSL协议，以确保ST和TGC的安全性。
CAS是如何实现SSO？
当用户访问另一个应用的服务再次被重定向到CAS Server的时候，CAS Server会主动获得到这个TGC cookie，然后做下面的事情：
1、如果User持有TGC且还没有失效，那么就发放票据即随机产生ST。
2、如果TGC失效，那么用户就要重新认证。
下面的时序图包括第一次登录，第二次登录，以及从已登录系统重定向到其他系统的时序图。
术语解释
CAS 系统中设计了 5 中票据： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
1、 Ticket-granting cookie(TGC) ：存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server 间通讯时使用，并于安且只能基全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭证；
2、 Service ticket(ST) ：服务票据，服务的惟一标识码 , 由 CAS Server 发出（ Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST ；
3、 Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力；
4、 Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。 Web 应用负责维护 PGTIOU 与 PGT 之间映射关系的内容表；
5、 Proxy Ticket (PT) ：是应用程序代理用户身份对目标程序进行访问的凭证；
其它说明如下：
1、Ticket Granting ticket(TGT) ：票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 (Credentials) ；
2、Authentication service(AS) --------- 认证用服务，索取 Credentials ，发放 TGT ；
3、Ticket-granting service (TGS) --------- 票据授权服务，索取 TGT ，发放 ST ；
4、KDC( Key Distribution Center ) ---------- 密钥发放中心；