How does cas work

How CAS works (原文http://www.alidw.com/?p=1529)

1 架构

1.1 The CAS server

CAS server：认证集中在唯一一台机器，called the CAS server。

CAS server 是整个架构中唯一知道用户密码的角色。

CAS server完成两件事情：

• 验证用户；

• 向CAS clients传输和证明已认证用户的身份。

1.2 浏览器

如果要使用cas的所有功能，对于浏览器有一些基本要求：

• 拥有https的加密引擎

• 支持http重定向、支持Javascript;

• 支持cookies. 尤其是在有安全需求的场景下，私有cookies只能传输给那些发放它们的机器。

这些基本需求常见的浏览器都有了，像ie、Netscape Navigator (4.7+) and Mozilla.

1.3 CAS clients

配置了cas客户端类库的web application或者是用mod_cas的web server都叫作CAS client。

2 基本功能

2.1 验证用户

没有认证（或者认证过期）的用户访问CAS server，会看到一个认证表单。在这个表单中输入用户名和密码登录认证。

 

 

访问CAS server

如果用户名密码正确，CAS server会发送一个TGC(Ticket Granting Cookie)给浏览器。

 

认证成功

TGC是用户访问CAS server的一个护照，有一定的生命周期（一般是几个小时）。有了TGC 客户端可以从CAS server获取tickets,不需要再二次认证。TGC是一个私有cookie(除了CAS server外不会传输给其他webserver)。CAS的ticket是浏览器和CAS server之间的一个会话标识，是不透明的。

2.2通过认证访问受保护的web资源

CAS客户端访问一个受保护的资源时，浏览器重定向到CAS server。

浏览器, 第一次认证后,得到TGC提供给CAS server。

根据TGC的描述，CAS server 交付一个Service Ticket（ST）。ST是不透明的，它不包含用户信息，只是用来告诉 application service我有好人标志，可以放行。同时CAS server重定向到浏览器去调用service。

 

认证之后浏览器重定向去调用service

CAS client 得到CAS server 交付的ST后，再到CAS server验证ST是否有效，验证成功之后再将资源交付给浏览器。

验证ST

上面所有的重定向操作对用户来说都是透明的。

ST可以看作是浏览器对CAS client的一个护照。ST是一次性的ticket，只由对应的CAS client来验证。ST的生命周期比较短，一般是几秒。

2.3 未认证时访问一个受保护的资源

如果没有认证, 请求将会被重定向到CAS server,。CAS server会返回一个认证表单的页面。

当你正确的填写用户名密码并提交表单时，CAS server会做两件事情：

• 发送给浏览器一个TGC;

• 重定向浏览器到所请求的应用service，重定向同时会带上一个ST过去。

3 复杂配置

3.1 CAS 代理

CAS可多层架构的特性使已认证的用户通过CAS client 访问一个后端service成为可能。例如通过一个CAS client代理认证。

最常用的CAS代理场景:

• Web portals, 通过用户身份认证访问外部应用。

• Webmail applications, 通过用户身份认证链接IMAP服务器收email。

在这样的多层架构下，CAS client不必再访问浏览器的cookie缓存，不需要重定向。

3.2 两层架构运行

CAS 代理端通过PGT (Proxy Granting Ticket)和ST验证用户：

PGT 是CAS代理端访问CAS server的passport。通过PGT，CAS 代理从CAS server获取访问后端service的tickets（不再需要验证ST了）。PGT是不透明的和可重用的ticket。由CAS server通过一个安全请求发放，确保PGT是完整和机密的。PGT的生命周期像TGC一样一般也是几个小时。

PGT对于application的作用就像前面TGC对于浏览器的作用一样。

PGT允许代理端应用到服务器认证并获取PT（ Proxy Tickets），在访问受保护的资源前，先验证PT：

 

验证PT

3.3 多层架构运行

CAS proxies can be chained: