CAS 原理

基础模式

1. 访问服务：  客户端发送请求访问应用系统提供的服务资源。

2. 定向认证：  客户端会重定向用户请求到 服务器。

3. 用户认证：用户身份认证。

4. 发放票据： 服务器会产生一个随机的 Service Ticket 。

5. 验证票据：服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。

6. 传输用户信息： 服务器验证票据通过后，传输用户认证结果信息给客户端。

代理模式

该模式形式为用户访问 App1 ， App1 又依赖于 App2 来获取一些信息。这种情况下，假设 App2 也是需要对 User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致 User 的 浏览器 窗口不停地闪动 ) ， CAS 引入了一种 Proxy 认证机制，即 CAS Client 可以代理用户去访问其它 Web 应用。

代理的前提是需要 CAS Client 拥有用户的身份信息 。PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据。凭借 TGC ， User 可以免去输入密码以获取访问其它服务的 Service Ticket 。

PGTURL 用于表示一个 Proxy 服务，是一个回调链接

PGT 相当于代理证

PGTIOU 为取代理证的钥匙，用来与 PGT 做关联关系

获取 PGT 的过程：

在验证 ST 时提供了一个额外的 PGTURL 给 CAS Server CAS Client 拿到了 PGT(PGTIOU-85 … )，就可以通过 PGT 向后端 Web 应用进行认证。

TGT、ST、PGT、PT之间关系

1）ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST, 然后把ST的值redirect到客户端应用。

2）PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PGTURL参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT。

3）PT是PGT签发的。CAS根据传来的PGT生成一个PT对象

为什么要PGTURL呢？为什么不是验证St时直接返回PGT？

假如hacker获取了ST，就可以通过ST到Server验证并获取PGT，这样导致所有应用都可以访问，而不只是ST所对应的服务了。 CAS要求PGTURL必须为Https。

CAS中的PGTIOU(Proxy Granting Ticket I Owe You )作用：

CAS调用PGTURL返回 PGTIOU和PGT

参考

CAS原理

jasig wiki: Proxy CAS Walkthrough