Apereo CAS 系统架构全解：服务器、客户端、协议与三大软件子系统

• 后端
• 认证鉴权
• 单点登录

CAS（Central Authentication Service）是一套面向全球 Web 应用的单点登录（SSO）解决方案。本文基于 Apereo CAS 官方文档 Architecture 展开，从物理组件（CAS Server 与 CAS Client）、支持的协议体系，以及 Web / Ticketing / Authentication 三层软件子系统三个维度，完整剖析一套 CAS 部署的构建模块。读完本文，你将掌握 CAS 服务器与客户端之间的票据交互模型、各协议适用场景，并能理解 Spring MVC、Spring Webflow、Spring Boot 在 CAS 内部的分工与扩展方式。

系统组件（System Components）

从物理部署角度看，CAS 系统架构由两个核心组件构成：CAS 服务器（CAS Server）与CAS 客户端（CAS Client）。两者通过多种受支持的协议进行通信，共同完成"一次登录、处处通行"的 SSO 体验。

CAS Server：票据的签发者与校验者

CAS Server 是一个基于 Spring Framework 构建的 Java Servlet 应用，它的核心职责是：

1. 认证用户（authenticate users）：验证用户提交的凭证（如用户名/密码、X.509 证书、MFA 令牌等）。
2. 签发与校验票据（issuing and validating tickets）：为接入的应用（即 CAS Client）授予访问权限。

CAS Server 通过两类核心票据维护 SSO 会话：

• Ticket-Granting Ticket（TGT）：用户登录成功后，服务器向其签发 TGT，TGT 的建立即代表一个SSO 会话的开启。在源码中，TicketGrantingTicket 接口定义了grantServiceTicket(...)方法——TGT 是用户进入 CAS 服务层的"主钥匙"（main access into the CAS service layer），没有 TGT，用户无法在 CAS 中执行任何操作。
• Service Ticket（ST）：当用户请求访问某个服务时，服务器应其请求、以 TGT 作为令牌通过浏览器重定向（browser redirects）向该服务签发 ST；随后应用通过后台通道（back-channel communication）将 ST 送回 CAS Server 进行校验。源码 ServiceTicket 接口明确了 ST 的用途："a service ticket is used to grant access to a specific service for a principal"，且ST 通常是一次性使用票据（one-time use ticket）。

提示：这一整套 TGT/ST 交互流程在 CAS Protocol 文档 中有非常详细的描述，建议结合阅读。

CAS Client：两种含义要分清

"CAS client" 在常见用法中有两种截然不同的含义：

1. 任何接入了 CAS 的应用：只要是能够通过受支持协议与 CAS Server 通信的应用，都可被称为 CAS client。
2. 软件集成包（software package）：指可以与各类软件平台和应用集成、从而通过某种认证协议（如 CAS、SAML、OAuth）与 CAS Server 通信的客户端库/模块。

CAS 官方为多种平台开发了客户端组件：

平台（Platforms）：

• Apache httpd Server（mod_auth_cas 模块）
• Java（Java CAS Client）
• .NET（.NET CAS Client）
• PHP（phpCAS）
• Perl（AuthCAS、Authen::CAS::Client）
• Python（python-cas）

应用（Applications）：

• Canvas
• Atlassian Confluence
• Atlassian JIRA
• Drupal
• Liferay
• uPortal
• 等更多

重要约定：在 CAS 手册中，若不加限定地使用 "CAS client" 一词，通常指的是集成组件（如 Java CAS Client），而非依赖 CAS Server 的应用本身。阅读文档时需注意区分。

支持的协议（Supported Protocols）

客户端通过若干受支持的协议之一与服务器通信。所有协议在概念上相似，但各有特性，适用于不同的应用场景：

示例：CAS 协议擅长委托（proxy）认证，适合代理场景；SAML 协议则支持属性释放（attribute release）和单点登出（single sign-out），适合企业联邦场景。

软件组件：三大分层子系统（Software Components）

为了便于理解，CAS Server 可以抽象为三个分层的子系统：

1. Web 层（Web）——基于 Spring MVC / Spring Webflow；
2. 票据子系统（Ticketing）——参考 Configuring-Ticketing-Components；
3. 认证子系统（Authentication）——参考 Configuring-Authentication-Components。

几乎所有的部署考量和组件配置都围绕这三个子系统展开：

• Web 层是所有外部系统（包括 CAS 客户端）通信的端点，负责接收和响应 HTTP 请求。
• Web 层将票据生成任务委托给票据子系统，为 CAS 客户端生成票据。
• SSO 会话始于成功认证后 TGT 的签发，因此票据子系统经常需要委托认证子系统完成认证。
• 认证子系统通常只在 SSO 会话开始时处理请求，但也有例外情况，例如强制认证（forced authentication）场景。

三层调用关系可以概括为：Web 层 → Ticketing 子系统 → Authentication 子系统，各层职责单一、通过委托解耦，这也是 CAS 具备高度可扩展性的架构基础。

票据子系统：TicketRegistry 与 ExpirationPolicy

在 Ticketing 层，有两个核心可配置组件（详见 Configuring-Ticketing-Components）：

• TicketRegistry：提供票据的持久化存储。部署环境与团队技术栈通常决定了选择哪种实现。缓存型实现（cache-backed）被推荐用于高可用（HA）部署，而默认的内存型注册表（in-memory registry）适合小型部署。源码中，默认实现 DefaultTicketRegistry 是"backed by a map"（基于ConcurrentHashMap）的内存注册表。
• ExpirationPolicy：提供票据过期语义的策略框架，支持 TGT、ST、PGT、PT、TST 等各类票据的过期策略定制（详见 Configuring-Ticket-Expiration-Policy）。

认证子系统：AuthenticationManager 与认证处理器

在 Authentication 层，认证流程主要由一个认证管理器（authentication manager）控制，它编排一组认证处理器（authentication handlers）。CAS 内置的认证管理器按以下契约执行认证：

1. 遍历所有已配置的认证处理器；
2. 若某个处理器支持该凭证，则尝试对其进行认证；
3. 成功后尝试解析 principal（主体）；
4. 检查是否为成功认证该凭证的处理器配置了 resolver；
5. 若找到合适的 resolver，则尝试解析 principal；
6. 若未找到合适的 resolver，则使用认证处理器解析出的 principal；
7. 检查安全策略（例如 any、all）是否满足；
8. 若安全策略满足则立即返回；
9. 若安全策略不满足则继续；
10. 在所有凭证尝试完毕后再次检查安全策略，若不满足则抛出AuthenticationException。

此外还存在一个隐式安全策略：至少需要一个处理器成功认证凭证。在源码中，AuthenticationManager 是一个@FunctionalInterface，其authenticate(AuthenticationTransaction)方法在成功时返回包含认证元数据的Authentication对象，失败则视为异常情况抛出AuthenticationException。

Spring Framework：CAS 的底座

CAS 大量使用了 Spring Framework 的方方面面，最突出的是：

• Spring MVC：承担 Web 层的 MVC 框架职责；
• Spring Webflow：用于定义和编排登录、登出等多步 Web 流程。

Spring 为 CAS 核心代码库以及部署方（deployers）提供了完整且可扩展的框架。通过钩住（hooking）CAS 与 Spring API 的扩展点，可以很方便地定制或扩展 CAS 行为。理解部分框架组件之间的协作关系需要一定的 Spring 基础，但并非强制要求。

Spring Boot：自动化配置

CAS 还重度基于Spring Boot：

• Spring Boot 让 CAS 对 Spring 平台与第三方库采取"有主见（opinionated）"的视角，以尽可能减少 XML 配置的方式构建独立运行的 Web 应用；
• Spring Boot 帮助 CAS隐藏其内部组件的许多复杂细节与配置，改为提供自动配置模块（auto-configuration modules），在运行期自动配置应用上下文，几乎无需人工干预。

这意味着部署方通常只需要修改 CAS 的 properties 配置，即可完成大部分组件装配，而无需手写大量 Spring XML bean 定义。

从架构到实战：一次完整的 SSO 登录流

将上述架构概念落到实际部署中，一次完整的 CAS SSO 登录（参考 Quick-Start）大致如下：

1. 用户在浏览器中访问应用https://app.example.org/，CAS 客户端检测到未认证，将浏览器重定向到http://localhost:8080/cas/login?service=https://app.example.org/；
2. CAS Server 的Web 层（Spring Webflow 驱动的登录流程）展示登录表单，用户提交凭证；
3. Authentication 子系统的认证管理器遍历认证处理器完成凭证校验，成功后签发 TGT（SSO 会话建立）；
4. 浏览器携带ticket=ST-…参数被重定向回应用；
5. 应用通过后台通道调用http://localhost:8080/cas/p3/serviceValidate?service=https://app.example.org/&ticket=ST-…校验 ST；
6. CAS Server 的Ticketing 子系统验证 ST 有效后返回<cas:user>等认证结果，应用据此建立本地会话。

这一流程中，三个子系统各司其职：Web 层负责协议端点与流程编排，Authentication 层负责凭证认证与 principal 解析，Ticketing 层负责票据的签发、存储与过期管理——正是前文架构描述的完整印证。

架构视角的部署建议

理解了架构后，一些常见的部署决策可以回归到架构本质上：

• 高可用与共享票据存储：多节点部署时，默认的内存型TicketRegistry无法跨节点共享，应选择共享型注册表（如 Redis、JPA、Hazelcast 等），并保证各节点服务定义一致（见 Configuring-Ticketing-Components 中的注册表对比表）。
• SSO 会话长度：TGT 的过期策略直接决定 SSO 会话时长，可在 Configuring-Ticket-Expiration-Policy-TGT 中选择 Default、Timeout、Hard Timeout、Throttled、Never 等策略；ST 则默认"固定使用次数 + 最大非活跃时长"双重过期，也可按应用定制（见 Configuring-Ticket-Expiration-Policy-ST）。
• 扩展与定制：得益于 Spring Framework 的扩展点和 Spring Boot 的自动配置，自定义认证处理器、票据注册表或 Webflow 流程，通常只需实现对应接口并加入模块依赖，即可挂载进三层子系统的对应位置。

小结

Apereo CAS 的架构可以用一张"组件—协议—子系统"三层图景概括：

• 物理组件：CAS Server（票据签发/校验）与 CAS Client（应用或客户端库），通过浏览器重定向与后台通道协作；
• 协议层：CAS 1/2/3、SAML1/2、OIDC、OAuth 2.0、WS Federation 等，按应用场景选用；
• 软件子系统：Web（Spring MVC/Webflow）→ Ticketing（TicketRegistry + ExpirationPolicy）→ Authentication（AuthenticationManager + Handlers），底层由 Spring Framework 与 Spring Boot 提供可扩展、可自动配置的支撑。

掌握这三层结构，是理解 CAS 一切配置项、模块与扩展机制的起点。更多细节可继续阅读 CAS 官方架构文档、CAS 协议规范 以及 配置属性大全。

• 后端
• 认证鉴权
• 单点登录