CAS（Central Authentication Service）协议简介

CAS（Central Authentication Service，中央认证服务）是一种协议和系统架构，旨在提供单点登录（SSO）功能。通过 CAS，用户只需要在一次登录时进行身份验证，就可以访问多个受保护的应用系统，而不需要再次输入凭据。CAS 通常被用于集中管理用户的身份验证，提高用户体验和安全性。

CAS 工作原理

CAS 的工作原理基于一个 客户端-服务器 模型，涉及以下几个主要角色：

1. 用户（User）：最终的使用者，尝试访问一个受保护的资源（应用）。
2. 服务提供者（Service Provider，SP）：托管应用程序的系统，用户想要访问的应用或资源。SP 不直接处理用户认证，而是将认证请求转发给 CAS 服务器。
3. CAS 服务器（Central Authentication Service Server，CAS Server）：负责用户的身份验证。CAS 服务器可以与 LDAP、数据库、Active Directory 等系统集成，验证用户凭证并生成一个票证（Ticket），授权用户访问受保护资源。

CAS 流程

CAS 的基本工作流程如下：

1. 用户请求访问 SP 资源

• 用户尝试访问某个服务提供者（SP）的受保护资源。例如，用户访问公司内部的某个 Web 应用。

2. SP 检查用户是否已认证

• SP 会检查用户是否已经登录。如果用户尚未登录，SP 会将用户重定向到 CAS 服务器进行认证。
• 重定向过程中，SP 会将自己的标识符和请求信息（如目标 URL）附加到请求中。

3. 用户重定向到 CAS 服务器

• 用户被重定向到 CAS 服务器。CAS 服务器会检查用户是否已经通过身份验证。
• 如果用户未登录，CAS 服务器会呈现登录页面，要求用户输入用户名和密码。

4. 用户登录 CAS 服务器

• 用户输入凭据，CAS 服务器对其进行验证。通常，CAS 服务器与 LDAP、数据库、Active Directory 等身份存储系统集成。
• 如果验证成功，CAS 服务器会生成一个认证票证（TGT，Ticket Granting Ticket），表示用户已成功认证。

5. CAS 服务器返回 TGT

• CAS 服务器将 TGT 返回给用户的浏览器。TGT 是一个临时的、加密的认证信息，通常保存在用户的浏览器中（如 Cookie）。

6. 用户请求服务资源

• 用户将携带的 TGT 再次发送到服务提供者（SP）。SP 会将 TGT 转发给 CAS 服务器，以验证用户身份。

7. CAS 服务器验证 TGT

• CAS 服务器验证 TGT 的有效性。如果 TGT 有效且未过期，CAS 服务器会向 SP 返回一个 服务票证（Service Ticket，ST），该票证包含用户的身份信息。

8. SP 验证 ST

• 服务提供者（SP）使用从 CAS 服务器获取的 ST 来验证用户身份。验证通过后，用户被授予访问资源的权限。

9. 用户访问资源

• 一旦身份验证成功，用户就可以访问受保护的资源。此后，用户无需再次登录，除非他们的会话过期或者退出登录。

10. 单点登出（Single Logout）

• 如果用户从任何一个受保护应用退出，CAS 可以提供单点登出功能，确保用户退出后所有相关的应用都清除登录状态。

CAS 票证概念

CAS 使用两个重要的票证来管理用户的认证过程：

1. TGT（Ticket Granting Ticket）：TGT 是一个加密的身份验证票证，表示用户已通过 CAS 服务器的认证。当用户第一次登录时，CAS 服务器会生成一个 TGT。TGT 在一段时间内有效，可以用来请求 ST（服务票证）。TGT 存储在客户端的 Cookie 中，并且与用户会话相关联。
2. ST（Service Ticket）：ST 是用于与特定服务提供者（SP）进行通信的票证。当用户访问 SP 时，SP 会使用用户的 TGT 来请求 ST。CAS 服务器根据 TGT 为用户生成 ST，并返回给 SP。SP 使用 ST 来验证用户的身份。

CAS 协议与流程示意图

CAS 流程简化为以下步骤：

1. 用户访问 SP用户试图访问受保护的 SP。
2. SP 重定向到 CAS如果用户尚未认证，SP 会将用户重定向到 CAS 服务器。
3. 用户在 CAS 登录用户登录到 CAS 服务器，CAS 服务器验证凭据。
4. CAS 返回 TGTCAS 服务器生成 TGT，并返回给用户的浏览器。
5. 用户请求 SP用户的浏览器向 SP 请求资源，并携带 TGT。
6. SP 向 CAS 发送 ST 请求SP 使用 TGT 请求 CAS 生成 ST。
7. CAS 返回 STCAS 验证并返回 ST 给 SP。
8. SP 验证 ST 并授权访问SP 验证 ST 并向用户提供访问权限。

用户        ->  SP                ->  CAS 服务器
 |               |                      |
 | 访问受保护资源  |                      |
 | -------------->|                      |
 |               |   重定向到 CAS 登录   |
 |               |--------------------->|
 |               |                      |
 |               |       用户登录        |
 |               |<---------------------|
 |               |                      |
 |               | 返回 TGT（认证票证）  |
 |<--------------|                      |
 |               |                      |
 |               |   请求服务资源       |
 | 访问资源 ---->|                      |
 |               |                      |
 |               |  提交 TGT 获取 ST    |
 |               |--------------------->|
 |               |                      |
 |               |  返回 ST（服务票证） |
 |               |<---------------------|
 |               |                      |
 |               |   验证 ST 并授予访问  |
 |<--------------|                      |
 |               |                      |
 |               |  访问资源成功        |

CAS 的优势与劣势

优点：

1. 简单易实现：CAS 相较于 SAML 和 OAuth 2.0，配置和实现相对简单，特别适合中小型企业和组织。
2. 集中管理：通过 CAS，用户只需在一个位置（CAS 服务器）进行认证，所有集成的应用都能够共享认证信息，减少了管理负担。
3. 跨应用支持：用户登录 CAS 后，能够跨多个应用访问，无需再次认证。
4. 高可扩展性：CAS 支持多种认证方式，灵活集成其他认证系统（如 LDAP、数据库等）。
5. 单点登出支持：CAS 支持单点登出功能，用户退出登录后，所有会话将同时被终止。

劣势：

1. 功能相对简单：CAS 比 SAML 更简单，缺乏一些高级功能（如细粒度授权控制），适用于大多数基本的身份验证需求，但对于复杂的身份管理需求（如联合身份管理）可能不足。
2. 仅适用于 Web 应用：CAS 主要用于 Web 应用的身份验证，对于非 Web 应用或需要跨协议的身份验证（如 API、移动应用）支持不如 OAuth 或 SAML。
3. 协议不如 SAML 标准化：CAS 协议本身不像 SAML 那样被广泛认定为国际标准，因此在一些国际化或跨国的应用中，可能需要额外的配置和集成。