一. CAS简介
CAS（Central Authentication Service）是 Yale大学发起的一个企业级的、开源的项目，旨在为 Web 应
用系统提供一种可靠的单点登录解决方法。CAS开始于2001年，并在2004年12月正式成为JA-SIG的一个项目。
二. CAS特性
1) 开源的、多协议的SSO解决方案，CAS Server和CAS Client通信支持多协议，如：CAS、Oauth、OpenID、
SAML1.1、SAML2.0D等。
2) 支持多种认证机制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates等。
3) 安全策略：使用票据（Ticket）来实现支持的认证协议；
4) 支持多种客户端：Java、.Net、PHP、Perl、Apache、 uPortal等。
5) 支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）。
6) 提供高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布式环
境的实现。
三. CAS体系结构
CAS包含CAS Server和CAS Client两个部分。
CAS Server负责完成对用户的认证工作，需要独立部署，CAS Server 会处理用户名/ 密码等凭证
(Credentials)。
CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到CAS Server
进行认证。原则上，客户端应用不再接受任何的用户名密码等。CAS Client与受保护的客户端应用部署在一起，以
Filter方式保护受保护的资源。
CAS框架图：
四. CAS协议
1. CAS 基础协议执行步骤如下：
1) 访问服务：用户发送请求访问应用系统（可称为CAS客户端）提供的受保护的服务资源。
2) 重定向认证：CAS客户端分析HTTP请求中没有Service Ticket（即ST）或SessionID，说明用户
还没有进行身份认证。于是，重定向用户请求到CAS服务器进行身份认证，并把用户此次访问CAS客户端的URL作为参
数（service）传递给CAS服务器。
3) 用户认证：CAS服务器接收到身份认证请求后转向登录页面，用户提供认证信息后进行身份认
证。身份认证成功后，CAS服务器以SSL方式给浏览器返回一个TGC（用户身份信息凭证，用于以后获取ST）。
4) 发放票据：CAS服务器会产生一个随机的ST，然后重定向到CAS客户端。
5) 验证票据：CAS客户端收到ST后，向CAS服务器验证票据ST的合法性，验证通过后，允许用户访
问客户端服务。
6) 传输用户信息：CAS服务器验证票据ST通过后，传输用户认证结果信息给客户端。
CAS基础协议流程图：
2. 代理协议：
CAS基础模式已经能够满足大部分简单的 SSO 应用。在另一种更复杂的情况下，即用户访问 helloservice，
helloservice又依赖于helloservice2 来获取一些信息，如同：
User -----> helloservice -----> helloservice2。
这种情况下，假设 helloservice2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验
（过多的重定向导致 User 的IE 窗口不停地闪动）， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理
用户去访问其它 Web 应用。
代理的前提是 CAS Client 要拥有用户的身份信息 ( 类似TGC ) ， 而PGT 就是CAS Client 持有的对用户
身份信息的一种凭据。凭借 TGC ， User 可以获取访问其它服务的ST，所以，凭借 PGT ，CAS Client可以从CAS
Server获取访问代理应用的PT，于是Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。
如下图所示，CAS Client 在基础协议之上，提供了一个额外的 PGT URL 给 CAS Server。于是，CAS
Server 可以通过 PGT URL 提供一个PGT 给 CAS Client 。
CAS Client访问应用流程图：
五. CAS安全性
CAS的安全性依赖于SSL，并且其安全性要求远高于普通的应用系统。
1. TGC/PGT 安全性
对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得，
Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问所有授权资源。
PGT 跟 TGC 的角色是一样的，如果被 Hacker 获得，后果可想而知。
从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常
大，从而确保 CAS 的安全性。另外，TGC也有自己的存活周期。下面是 CAS 的 web.xml 中，通过 grantingTimeout
来设置 CAS TGC 存活周期的参数，参数默认是 120 分钟，在合适的范围内设置最小值，太短，会影响 SSO 体验，
太长，会增加安全性风险。
<context-param>
<param-name>edu.yale.its.tp.cas.grantingTimeout</param-name>
<param-value>7200</param-value>
</context-param>
2. ST/PT 安全性
ST是通过 HTTP 传送的，所以ST可以被截取到 。CAS 协议从几个方面让 ST变得更加安全。
1) Service Ticket 只能使用一次。CAS 协议规定，无论 Service Ticket 验证是否成功， CAS
Server 都会将服务端的缓存中清除该 Ticket ，从而可以确保一个 Service Ticket 仅被使用一次。
2) ST 在一段时间内失效，默认5分钟。
3) ST是随机产生的。
六.CAS相关术语
CAS系统中设计了5种票据：TGC、ST、PGT、PGTIOU、PT。
Ticket-granting cookie（TGC）：存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，
并且只能基于安全通道传输（HTTPS），是CAS Server用来明确用户身份的凭证。
Service ticket （ST）：服务票据，服务的惟一标识码,由CAS Server发出（HTTP传送），通过客户端浏览
器到达业务服务器端；一个特定的服务只能有一个惟一的ST。
Proxy-Granting ticket（PGT）：由CAS Server颁发给拥有ST凭证的服务，PGT绑定一个用户的特定服务，使
其拥有向CAS Server申请，获得PT的能力。
Proxy-Granting Ticket I Owe You（PGTIOU）：将通过凭证校验时的应答信息由CAS Server 返回给CAS
Client，同时，与该PGTIOU对应的PGT将通过回调链接传给Web应用。Web应用负责维护PGTIOU与PGT之间映射关系的
内容表。
Proxy Ticket（PT）：是应用程序代理用户身份对目标程序进行访问的凭证。