CAS登录工作流程简述

一、CAS登录的核心概念

CAS（Central Authentication Service）是实现单点登录（SSO）的开源框架，其核心目标是让用户在多个应用系统中只需登录一次，即可访问所有相互信任的资源。CAS由CAS Server（认证中心）和CAS Client（客户端应用）组成：

• CAS Server：独立部署，负责用户认证、生成票据（Ticket）和管理用户会话。
• CAS Client：集成在各应用系统中，拦截未认证请求，重定向用户至CAS Server，并验证票据有效性。

二、工作流程深度解析

CAS登录流程分为首次登录、二次访问和跨系统访问三种场景，核心步骤如下：

1. 首次访问受保护资源

1. 客户端拦截请求：用户访问应用系统（如http://app.example.com），CAS Client的过滤器检测到用户未登录，重定向至CAS Server的登录页面，携带参数service=http://app.example.com/cas/login。
2. 用户输入凭证：用户在CAS Server登录页面输入用户名和密码，提交后CAS Server验证凭证（如查询数据库或LDAP）。
3. 生成TGT与TGC：认证成功后，CAS Server生成Ticket Granting Ticket（TGT）（存储在服务器内存或数据库），并在浏览器Cookie中写入Ticket Granting Cookie（TGC），其值为TGT的ID。
4. 颁发Service Ticket（ST）：CAS Server用TGT生成一次性票据ST，并将用户重定向回客户端应用，URL形如http://app.example.com/cas/login?ticket=ST-123。
5. 验证ST：客户端应用收到ST后，调用CAS Server的serviceValidate接口验证ST有效性。CAS Server检查ST是否关联有效TGT，若有效则返回用户信息（如用户名、权限）。
6. 创建本地会话：客户端应用基于验证结果创建本地会话，用户后续请求通过会话标识（如JSESSIONID）直接访问资源。

2. 二次访问与跨系统访问

• 二次访问：用户再次访问同一应用时，客户端通过Cookie中的JSESSIONID获取本地会话，直接放行请求，无需重复认证。
• 跨系统访问：用户访问另一应用（如http://mail.example.com），该应用的CAS Client检测到未登录，重定向至CAS Server。此时浏览器携带TGC，CAS Server根据TGC找到对应TGT，生成新的ST并返回给新应用，实现单点登录。

跨系统访问（已登录）流程图：

三、核心原理：票据机制与安全设计

CAS的核心机制围绕TGT、ST、TGC展开，结合安全策略确保认证可靠：

1. 票据类型与作用

• TGT（Ticket Granting Ticket）：用户登录成功后，CAS Server生成的长期凭证，存储在服务器端。TGT可用于签发多个ST，每个ST对应一个客户端应用。
• ST（Service Ticket）：由TGT生成的一次性票据，仅能使用一次且有有效期（默认10秒，可配置延长）。ST验证失败后，CAS Server立即销毁该票据，防止重放攻击。
• TGC（Ticket Granting Cookie）：存储在用户浏览器的Cookie，值为TGT的ID。客户端通过TGC与CAS Server交互，避免直接传输敏感信息。

2. 安全增强机制

• 票据唯一性：ST和TGT均通过随机算法生成，难以被猜测。
• 超时机制：ST和TGT均设置有效期，减少凭证泄露风险。例如，ST默认10秒失效，TGT默认24小时有效。
• HTTPS强制：CAS Server与客户端之间的通信建议使用HTTPS，防止票据在传输中被窃取。