跳到主要内容
版本：4.1.x

CAS协议

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）

CAS体系结构​

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

cas1

CAS原理​

CAS 最基本的协议过程：

cas1

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 官方网站上的相关文档。

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签发的。