CAS基础以及代理票据原理详解

图1

图1是一个最基础的 CAS 协议， CAS Client 以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket( 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的，于是， CAS Client 会重定向用户请求到 CAS Server （ Step 2 ）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials（认证信息）， CAS Server 会产生一个随机的 Service Ticket ，然后，缓存该Ticket ，并且重定向用户到 CAS Client （附带刚才产生的 Service Ticket ）， Service Ticket 是不可以伪造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实，用 Ticket 查到 Username ，因为 Ticket 是 CAS Server 产生的，因此，所以 CAS Server 的判断是毋庸置疑的。

图2

图2中该协议完成了一个很简单的任务，就是 User(david.turing) 打开 IE ，直接访问 helloservice 应用，它被立即重定向到 CAS Server 进行认证， User 可能感觉到浏览器在 helloservcie 和 casserver 之间重定向，但 User 是看不到， CAS Client 和 CAS Server 相互间的 Service Ticket 核实 (V alidation) 过程。当 CAS Server 告知 CAS Client 用户 Service Ticket 对应确凿身份， CAS Client 才会对当前 Request 的用户进行服务。

CAS如何实现SSO

当我们的Web 时代还处于初级阶段的时候，SSO 是通过共享cookies 来实现，比如，下面三个域名要做SSO ：

如果通过CAS 来集成这三个应用，那么，这三个域名都要做一些域名映射，

因为是同一个域，所以每个站点都能够共享基于 的cookies 。这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。

CAS 可以很简单的实现跨域的SSO ，因为，单点被控制在CAS Server ，用户最有价值的TGC-Cookie 只是跟CAS Server 相关，CAS Server 就只有一个，因此，解决了cookies 不能跨域的问题。

回到CAS 的基础协议图，当Step3 完成之后，CAS Server 会向User 发送一个Ticket granting cookie (TGC) 给User 的浏览器，这个Cookie 就类似Kerberos 的TGT ，下次当用户被Helloservice 重定向到CAS Server 的时候，CAS Server 会主动Get 到这个TGC cookie ，然后做下面的事情：

1，如果User 的持有TGC 且其还没失效，那么就走基础协议图的Step4 ，达到了SSO 的效果。

2，如果TGC 失效，那么用户还是要重新认证( 走基础协议图的Step3) 。CAS 的代理模式

模式1 已经能够满足大部分简单的SSO 应用，现在，我们探讨一种更复杂的情况，即用户访问helloservice ，helloservice 又依赖于helloservice2 来获取一些信息，如同：

User à helloservice à helloservice2

这种情况下，假设helloservice2 也是需要对User 进行身份验证才能访问，那么，为了不影响用户体验（过多的重定向导致User 的IE 窗口不停地闪动) ，CAS 引入了一种Proxy 认证机制，即CAS Client 可以代理用户去访问其它Web 应用。

代理的前提是需要CAS Client 拥有用户的身份信息( 类似凭据) 。与其说之前我们提到的TGC 是用户持有对自己身份信息的一种凭据，则这里的PGT 就是CAS Client 端持有的对用户身份信息的一种凭据。凭借TGC ，User 可以免去输入密码以获取访问其它服务的Service Ticket ，所以，这里，凭借PGT ，Web 应用可以代理用户去实现后端的认证，而无需前端用户的参与。

如下面的CAS Proxy 图所示，CAS Client 在基础协议之上，提供了一个额外的PGT URL 给CAS Server, 于是，CAS Server 可以通过PGT URL 提供一个PGT 给CAS Client 。

图3

初学者可能会对上图的PGT URL 感到迷惑，或者会问，为什么要这么麻烦，要通过一个额外的URL( 而且是SSL 的入口) 去传递PGT ？如果直接在Step 6 返回，则连用来做对应关系的PGTIOU 都可以省掉。PGTIOU 设计是从安全性考虑的，非常必要，CAS 协议安全性问

题我会在后面一节介绍。

于是，CAS Client 拿到了PGT( PGTIOU-85…..ti2td ) ，这个PGT 跟TGC 同样地关键，CAS Client 可以通过PGT 向后端Web 应用进行认证。如图4所示，Proxy 认证与普通的认证其实差别不大，Step1, 2 与基础模式的Step 1,2 几乎一样，唯一不同的是，Proxy 模式用的是PGT 而不是TGC ，是Proxy Ticket （PT ）而不是Service Ticket 。

最终的结果是，helloservice2 明白helloservice 所代理的客户是David. Turing 同学，同时，根据本地策略，helloservice2 有义务为PGTURL=http://helloservice/proxy 服务(PGTURL 用于表示一个Proxy 服务) ，于是它传递数据给helloservice 。这样，helloservice 便完成一个代理者的角色，协助User 返回他想要的数据。

(PGT相当于TGC，PT相当于ST)。。。