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