CAS登录工作流程简述
文章目录
- 一、CAS登录的核心概念
- 二、工作流程深度解析
- 1. 首次访问受保护资源
- 2. 二次访问与跨系统访问
- 三、核心原理:票据机制与安全设计
- 1. 票据类型与作用
- 2. 安全增强机制
一、CAS登录的核心概念
CAS(Central Authentication Service)是实现单点登录(SSO)的开源框架,其核心目标是让用户在多个应用系统中只需登录一次,即可访问所有相互信任的资源。CAS由CAS Server(认证中心)和CAS Client(客户端应用)组成:
- CAS Server:独立部署,负责用户认证、生成票据(Ticket)和管理用户会话。
- CAS Client:集成在各应用系统中,拦截未认证请求,重定向用户至CAS Server,并验证票据有效性。
二、工作流程深度解析
CAS登录流程分为首次登录、二次访问和跨系统访问三种场景,核心步骤如下:
1. 首次访问受保护资源
- 客户端拦截请求:用户访问应用系统(如
http://app.example.com
),CAS Client的过滤器检测到用户未登录,重定向至CAS Server的登录页面,携带参数service=http://app.example.com/cas/login
。 - 用户输入凭证:用户在CAS Server登录页面输入用户名和密码,提交后CAS Server验证凭证(如查询数据库或LDAP)。
- 生成TGT与TGC:认证成功后,CAS Server生成Ticket Granting Ticket(TGT)(存储在服务器内存或数据库),并在浏览器Cookie中写入Ticket Granting Cookie(TGC),其值为TGT的ID。
- 颁发Service Ticket(ST):CAS Server用TGT生成一次性票据ST,并将用户重定向回客户端应用,URL形如
http://app.example.com/cas/login?ticket=ST-123
。 - 验证ST:客户端应用收到ST后,调用CAS Server的
serviceValidate
接口验证ST有效性。CAS Server检查ST是否关联有效TGT,若有效则返回用户信息(如用户名、权限)。 - 创建本地会话:客户端应用基于验证结果创建本地会话,用户后续请求通过会话标识(如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,防止票据在传输中被窃取。