第15章：Apereo CAS — 开源企业级 IAM 单点登录与 CAS 协议详解 | IDaaS Book
15.1 CAS 简介
Apereo CAS（Central Authentication Service）是教育和技术社区最古老、最广泛使用的开源 SSO 解决方案之一。始于耶鲁大学（2002年），现由 Apereo 基金会维护。
CAS 的定位是：专注于 Web SSO 的认证服务器，提供了丰富的协议支持和现代的身份管理能力。
15.2 CAS 与 Keycloak 的定位差异
| 维度 | CAS | Keycloak |
|---|---|---|
| 起源 | 教育领域（耶鲁大学） | 企业领域（Red Hat） |
| 设计哲学 | 高度可配置，Assembly Line | 开箱即用，约定优于配置 |
| 扩展方式 | 依赖注入，丰富的模块 | SPI 机制 |
| 用户管理 | 委派给外部源 | 自有用户存储 + 联合 |
| 协议支持 | CAS 协议、SAML 2.0、OIDC、OAuth 2.0、WS-Federation | OIDC、OAuth 2.0、SAML 2.0（不原生支持 WS-Fed） |
| 文档质量 | 一般 | 好 |
| 社区 | 教育+研究机构为主 | 更广泛的企业社区 |
| 容器化友好度 | 需要定制构建 | 原生支持 |
选型建议：
- 如果你的环境主要是 Java 生态，需要高度定制化 → CAS
- 如果你需要快速部署，开箱即用 → Keycloak
- 如果你在教育领域，已有 CAS 基础设施 → 继续用 CAS
15.3 CAS 架构
核心设计：Assembly Line
CAS 使用"装配线"模式处理认证请求：
请求 → [解析器] → [服务管理] → [认证引擎] → [策略引擎] → [主题] → [审计] → 响应
│ │
这是什么服务？ 用户如何认证？CAS 6.x 基于 Spring Boot / Spring Cloud，整个系统高度模块化。当前主线是 8.0.x：8.0.0 于 2026-07-18 发布，最新补丁 8.0.2 于 2026-09-26 发布（ Releases，核对日期 2026-10-07）。仓库里也能看到 8.1.0 的 RC，但 RC 不是可上线版本，生产应停在 8.0.x 补丁线上。
Apereo CAS 官方维护策略把版本线分成"常规维护 → 仅安全补丁（SPM）→ EOL"三段：常规维护 6 个月，之后 6 个月只接受安全补丁，到期即 EOL；不在维护表里的版本一律视为已 EOL（ Maintenance Policy）：
| 版本线 | 最新发布 | JDK 基线 | 仅安全补丁（SPM）起 | 完全 EOL |
|---|---|---|---|---|
8.0.x | 8.0.2（2026-09-26） | 25 | 2027-01-17 | 2027-07-17 |
7.3.x | 7.3.8.3（2026-09-22） | 21 | 2026-06-30（已进入） | 2026-12-31 |
7.2.x 及更早 / 6.x | — | — | — | 已 EOL |
JDK 基线取自各版本线的官方 Installation Requirements（ 7.3.x / 8.0.x）。官方只在主版本变更时调整 Java 平台要求，所以 8.0.x 内部的补丁升级不会再动 JDK；反过来说，跨主版本升级时构建与运行时 JDK 必须一起换，这一步经常被留到最后才发现。
选版本时有两个容易踩的判断：
- 不要按"LTS"选：CAS 项目明确表示无法提供 LTS 版本（原文：“the CAS project can not offer LTS releases in a practical and sustainable sense”）。选型只能看维护窗口，没有一条可以依赖数年的长期支持线。
- 7.3.x 已经在倒计时：2026-06-30 起进入安全补丁模式、不再接受常规改动，2026-12-31 完全 EOL。新项目应直接基于 8.0.x；留在 7.3.x 的存量部署需要在年底前完成升级评估，第一步是 JDK 21 → 25 的兼容性验证。
版本能力差异与场景推荐另见 开源 IAM 对比与选型指南。
核心组件
Central Authentication Service (CAS Server)：
- 基于 Spring Webflow 的 Web 应用
- 通过 WAR Overlay 方式部署
- 内置丰富的认证处理器（LDAP、JDBC、X.509、多种 MFA、社交 IdP 等）
Service Registry：
- 管理哪些服务可以使用 CAS
- 支持 JSON、YAML、LDAP、MongoDB、JPA 等多种存储
Ticket Registry：
- 管理 TGT（Ticket Granting Ticket）和 ST（Service Ticket）
- 支持内存、Hazelcast、Redis、Memcached 等
15.4 CAS 协议
CAS 协议是 CAS 自有的 SSO 协议（不要与 CAS 软件混淆）。
核心流程
1. 用户访问 Service-A（如 Jira）
2. Service-A 重定向到 CAS Server
3. 用户认证，获得 TGT Cookie（存在浏览器）
4. CAS 签发 ST（Service Ticket），重定向回 Service-A
5. Service-A 将 ST 发送到 CAS Server 验证
6. CAS 验证后返回用户身份信息
后续访问 Service-B：
1. 用户访问 Service-B
2. Service-B 重定向到 CAS Server
3. CAS 看到浏览器已有 TGT → 直接签发 ST
4. 用户无缝登录 Service-BCAS v1 / v2 / v3 协议区别
- CAS v1：仅返回用户 principal（纯文本）
- CAS v2：XML 响应，支持属性，并引入 PGT/PT 代理认证机制
- CAS v3：支持 JSON 响应，属性语义增强，代理认证链（proxy chain）完善
15.5 Docker 部署
CAS 提供 Docker 基础镜像，但通常需要基于 Overlay 自定义：
下例只示意 Overlay 的目录结构与启动参数，
FROM的 tag 请以 官方发布页 为准：6.x 与 7.2.x 及更早版本都已 EOL，7.3.x 将于 2026-12-31 EOL，生产应基于 8.0.x，并按 JDK 25 基线构建与运行（7.3.x 为 JDK 21，官方只保证不低于该基线、不保证更高 JDK 上一定正常）。
FROM apereo/cas:<当前 8.0.x 补丁版本> # tag 以官方发布页为准，不要照抄本文
# 复制配置文件
COPY etc/cas/config/ /etc/cas/config/
COPY build/libs/cas.war /cas-overlay/
# 自定义启动配置
ENV CAS_CONTEXT_PATH="/cas"
ENV SERVER_PORT=8443
ENV SPRING_PROFILES_ACTIVE="standalone"
EXPOSE 8443
CMD ["run"]15.6 CAS 最佳实践
- 使用 WAR Overlay：不要修改 CAS 源码，通过 Overlay 定制
- 外部化配置：所有配置应通过 Spring Cloud Config 或配置文件管理
- 票据注册中心：生产环境使用 Redis，而不是内存
- 日志聚合：CAS 日志应该集中收集
- 监控：CAS 提供 Actuator 端点，可暴露 Prometheus 指标
15.7 小结
Apereo CAS 在教育和技术社区拥有深厚的用户基础。虽然 Keycloak 在新项目中更受欢迎，但 CAS 的高度可定制性和广泛的协议支持在某些场景中无可替代。如果要与现有的 CAS 生态集成，或者在需要同时支持多种"非标准"认证方式的环境中，CAS 是很好的选择。