简介

CAS 是 Central Authentication Service(中央认证服务)的简写,旨在在 Web 应用系统提供可靠的单点登录(Single Sign On)方法。CAS 目前在 Github 上管理其代码,遵循 Apache 2.0 协议。


协议过程

CAS 分为 CAS Server 和 CAS Client 两部分。CAS Server 独立部署,主要负责对用户的认证工作。CAS Client(我们的 Web App)负责处理客户端对受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图是 CAS 协议的过程:

cas-sd.png

接下来通过抓包辅助理解该过程:

1,用户访问 Web App http://192.168.56.1:9876/,因为请求的 Cookie 中没有 Session Key,所以被重定向到 CAS Server Login Endpoint https://cas.server.com:8443/cas/login

请求:

响应:

注意:

  1. 需要为 CAS Server Login Endpoint 添加 service 参数

2,用户的浏览器自动跳转到 CAS Server Login Endpoint,因为 Cookie 中没有 TGC,所以返回登陆页面,让用户登录

请求:

响应(Body 已省略):

3,用户完成登录后,CAS Server 设置 TGC Cookie,并重定向到 Web App 通过 service 参数指定的 URL 上

登陆请求(Body 已省略):

响应:

注:

  1. CAS Server 为 Web App 回调 URL 增加 ticket 参数,其值为 Service Ticket,Service Ticket 有时间(默认 10 秒)和使用次数限制(默认 1 次)

4,用户的浏览器自动跳转到 Web App 通过 service 参数指定的重定向 URL,Web App 在后台调用 CAS Server ServiceValidate Endpoint,验证通过后,在响应的 Cookie 中设置自己的 Session Key,并将用户重定向到其它页面,防止泄漏 Service Ticket

请求:

响应:

注:

  1. CAS Client 和 CAS Server 间验证 Service Ticket 的过程对用户透明

5,用户的浏览器自动跳转到 Web App 指定的重定向 URL 上,浏览器自动提交 Web App 设置的 Cookie,Web App 验证通过后,给用户下发资源

请求:

响应(Body 已省略):


术语介绍

  1. Ticket Granting Ticket(TGT)

    TGT 是 CAS Server 为用户签发的登陆票据,拥有 TGT 可以证明用户成功登陆 CAS。TGT 封装 Cookie 值及对应的用户信息。用户在 CAS 认证成功后,CAS 生成 Cookie(TGC),写到浏览器,同时生成 TGT 对象,放入 Ticket Registry,TGT 对象的 ID 就是 Cookie 的值

  2. Ticket Granting Cookie(TGC)

    存放用户身份认证凭证的 Cookie

  3. Service Ticket(ST)

    用户访问 Service 时,Service 发现用户没有 ST,则要求用户去 CAS Server 获取 ST。用户向 CAS Server 发出获取 ST 的请求时,如果 CAS Server 发现用户有 TGT,则签发 ST,返回给用户。用户拿着 ST 去访问 Serivce,Service 拿 ST 去 CAS Server 验证,验证通过后,允许用户访问资源