CAS 单点登录详细流程

转自：CAS 单点登录详细流程

一、CAS 简介和整体流程

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

1. 开源的企业级单点登录解决方案。

2. CAS Server 需要独立部署，是一个 Web 应用，主要负责用户认证。

3. CAS Client 支持多种客户端（即单点登录系统中的各个 Web 应用），包括 Java、.Net、PHP、Perl、Apache、uPortal、Ruby 等。

从结构上看，CAS 包含两个部分：CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责用户认证；CAS Client 负责处理客户端受保护资源的访问请求。当需要登录时，会重定向到 CAS Server。

下图是 CAS 最基本的协议过程：

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

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

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

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

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

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

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

二、详细登录流程

上图展示了 3 个登录场景，分别为：第一次访问 www.qiandu.com、第二次访问、以及登录状态下第一次访问 mail.qiandu.com。

下面详细说明上图中每个数字标号的含义，以及相关的请求内容和响应内容。

1. 第一次访问 www.qiandu.com

标号 1：用户访问 www.qiandu.com，经过其第一个过滤器（CAS 提供，在 web.xml 中配置）AuthenticationFilter。

• 过滤器全称：org.jasig.cas.client.authentication.AuthenticationFilter
• 主要作用：判断是否登录，如果没有登录则重定向到认证中心。

标号 2：www.qiandu.com 发现用户没有登录，则返回浏览器重定向地址。

首先可以看到我们请求 www.qiandu.com，之后浏览器返回状态码 302，然后让浏览器重定向到 cas.qiandu.com，并通过 GET 方式添加参数 service。该参数的目的是登录成功后重定向回来，因此需要该参数。你会发现，service 的值其实就是编码之后的我们请求 www.qiandu.com 的地址。

标号 3：浏览器接收到重定向后，发起重定向请求到 cas.qiandu.com。

标号 4：CAS 认证中心 cas.qiandu.com 接收到登录请求，返回登录页面。

上图就是标号 3 的请求，以及标号 4 的响应。请求的 URL 是标号 2 返回的 URL。之后 CAS 认证中心展示登录页面，等待用户输入用户名和密码。

标号 5：用户在 cas.qiandu.com 的登录页面输入用户名和密码并提交。

标号 6：服务器接收到用户名和密码后，验证其有效性。验证逻辑可以使用 cas-server 提供的，也可以自定义实现。

上图是标号 5 的请求和标号 6 的响应。当 cas.qiandu.com（即 CAS Server）认证通过后，会返回给浏览器 302，重定向的地址就是 service 参数对应的值，并通过 GET 方式携带一个 ticket 令牌（即 ST）。同时会在 Cookie 中设置一个 CASTGC，该 Cookie 仅在访问 cas.qiandu.com 时携带。

• CASTGC：向 Cookie 中添加该值的目的是下次访问 cas.qiandu.com 时，浏览器会携带 Cookie 中的 TGC 到服务器，服务器根据 TGC 查找对应的 TGT，从而判断用户是否已登录，是否需要展示登录页面。TGT 与 TGC 的关系类似于 Session 与 Cookie 中 SessionID 的关系。
• TGT（Ticket Granting Ticket）：俗称大令牌或票根，可以签发 ST。
• TGC（Ticket Granting Cookie）：存储在 Cookie 中的值，根据它可以找到 TGT。
• ST（Service Ticket）：由 TGT 生成，默认一次性有效，即上面数字 3 处的 ticket 值。

标号 7：浏览器从 cas.qiandu.com 拿到 ticket 后，根据指示重定向到 www.qiandu.com，请求的 URL 就是上面返回的 URL。

标号 8：www.qiandu.com 在过滤器中获取 ticket 的值，然后通过 HTTP 方式调用 cas.qiandu.com 验证该 ticket 是否有效。

标号 9：cas.qiandu.com 接收到 ticket 后进行验证，验证通过后返回结果告知 www.qiandu.com 该 ticket 有效。

标号 10：www.qiandu.com 接收到 CAS Server 的返回，确认用户合法，向用户浏览器展示相关资源。

至此，第一次访问的整个流程结束。其中标号 8 与标号 9 的环节是通过代码调用的，并不是浏览器发起的，所以没有截取到报文。

2. 第二次访问 www.qiandu.com

上面已经访问过一次了，当第二次访问时会发生什么？

标号 11：用户发起请求，访问 www.qiandu.com。会经过 CAS Client，也就是过滤器。因为第一次访问成功后，www.qiandu.com 会在 Session 中记录用户信息，因此这里直接通过，无需再次验证。

标号 12：用户通过权限验证，浏览器返回正常资源。

3. 访问 mail.qiandu.com

标号 13：用户在 www.qiandu.com 正常上网，突然想访问 mail.qiandu.com，于是发起访问 mail.qiandu.com 的请求。

标号 14：mail.qiandu.com 接收到请求，发现是第一次访问，于是给出一个重定向地址，让用户去 CAS 认证中心登录。

上图可以看到，用户请求 mail.qiandu.com，然后返回给他一个网址，状态 302 重定向，service 参数就是回来的地址。

标号 15：浏览器根据 14 返回的地址发起重定向。由于之前访问过一次 CAS Server，这次会携带上次返回的 Cookie：TGC 到认证中心。

标号 16：CAS 认证中心收到请求，发现 TGC 对应了一个 TGT，于是用 TGT 签发一个 ST，并返回给浏览器，让其重定向到 mail.qiandu.com。

可以发现请求时携带了 Cookie：CASTGC，响应的是一个带有 TGT 签发的 ST（即 ticket）的地址。

标号 17：浏览器根据 16 返回的网址发起重定向。

标号 18：mail.qiandu.com 获取 ticket 后去 CAS 认证中心验证其有效性。

标号 19：认证成功，mail.qiandu.com 在 Session 中设置登录状态，下次就可以直接登录。

标号 20：认证成功后，返回用户想要访问的资源。