1 CAS简介

CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法,CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点:

CAS的目标是允许用户访问多个应用程序只提供一次用户凭据(如用户名和密码)。它还允许Web应用程序对用户进行身份验证,而不必获取用户的安全凭证,比如密码。

  1. 一个开放的,文档齐全的协议。
  2. 开源的JAVA服务器组件。
  3. CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
  4. 与uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle等等能很好集成。
  5. 文档社区化和实现的支持。
  6. 具有广泛的客户群的支持。
扩展阅读参看:官方技术说明CAS官方网站(en) CAS维基百科(en)

2 CAS体系结构

CAS 体系包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。

3 CAS原理

CAS 最基本的协议过程:

SSO单点登录访问流程主要有以下步骤:

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

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

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

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

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

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

CAS Client 与受保护的客户端应用部署在一起,以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求,CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket,如果没有,则说明当前用户尚未登录,于是将请求重定向到指定好的 CAS Server 登录地址,并传递 Service (也就是要访问的目的资源地址),以便登录成功过后转回该地址。用户在第 3 步中输入认证信息,如果登录成功,CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket,并缓存以待将来验证,之后系统自动重定向到 Service 所在地址,并为客户端浏览器设置一个 Ticket Granted Cookie(TGC),CAS Client 在拿到 Service 和新产生的 Ticket 过后,在第 5,6 步中与 CAS Server 进行身份合适,以确保 Service Ticket 的合法性。

在该协议中,所有与 CAS 的交互均采用 SSL 协议,确保,ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

另外,CAS 协议中还提供了 Proxy (代理)模式,以适应更加高级、复杂的应用场景,具体介绍可以参考 CAS 官方网站上的相关文档。

4 CAS中3个术语

Ticket Granting ticket (TGT) :可以认为是CAS Server根据用户名密码生成的一张票,存在Server端

Ticket-granting cookie (TGC) :其实就是一个Cookie,存放用户身份信息,由Server发给Client端

Service ticket (ST) :由TGT生成的一次性票据,用于验证,只能用一次。相当于Server发给Client一张票,然后Client拿着这个票再来找Server验证,看看是不是Server签发的。