知识库
CAS 单点登录协议详解：原理、版本和迁移
发布
CAS（Central Authentication Service）最早由耶鲁大学开发，因为简单易接，在国内高校的统一身份认证里用得非常普遍。
CAS 的票据流程
- 用户访问业务系统，系统发现没登录，把浏览器重定向到 CAS 服务器的 /login，并带上 service 参数（业务系统自己的地址）。
- 用户在 CAS 登录页登录。CAS 服务器创建一个票据授予票据（TGT），保存在 CAS 域名下的 Cookie 里，代表“这个浏览器已经登录”。
- CAS 服务器签发一个一次性的服务票据（ST），把浏览器重定向回 service 地址并附上 ticket 参数。
- 业务系统在后台拿 ST 调用 CAS 服务器的校验接口，校验通过后得到用户名（以及属性），建立自己的会话。
- 用户访问第二个业务系统时，CAS 服务器看到 TGT，直接签发新的 ST，不再要求登录。
CAS 1.0、2.0、3.0 的区别
- CAS 1.0：校验接口 /validate 只返回 yes 或 no 和用户名，纯文本格式。
- CAS 2.0：校验接口 /serviceValidate 返回 XML，引入了代理票据，可以让一个服务代表用户访问另一个服务。
- CAS 3.0：增加 /p3/serviceValidate，可以在校验结果里返回用户属性（如姓名、工号、院系），并支持 SAML 1.1 格式的校验。
CAS 和 OIDC 的对比
CAS 的优点是简单：业务系统只需要会做一次重定向、调一次校验接口。但它也有局限：没有标准的令牌格式，不适合前后端分离和移动 App，不能顺带拿到调用 API 的授权，各家实现的属性返回也不完全一致。新系统建议用 OIDC，已有的 CAS 系统则没必要强行改造。
从旧 CAS 平台迁移
很多高校的统一身份认证平台建于十多年前，基于 CAS，接着几十上百个业务系统，平台本身已经难以维护，也不支持多因素认证和信创。迁移的关键是让业务系统尽量少改动：
- 新平台要原生支持 CAS，并且返回的用户名和属性格式与旧平台一致，业务系统只需要把 CAS 地址改成新平台的。
- 先把账号同步到新平台：从人事、学工、教务系统的数据库或 LDAP 同步教职工和学生。
- 新旧平台并行，选一两个系统试点，确认登录、登出和属性都正确。
- 按批次切换其他系统，旧平台保留一段时间作为回退。
- 迁移完成后，在新平台上统一开启多因素认证，逐步把新系统改用 OIDC。
Casdoor 对 CAS 的支持
Casdoor 原生支持 CAS 协议，可以直接替代旧的 CAS 服务器，同时提供 OIDC、SAML、LDAP 和 RADIUS，让新老系统、校园网和 VPN 都用同一套账号。信创版适配国产软硬件，企业版提供国密和等保合规能力，并包含迁移方案的规划和远程协助。