当前位置: 首页 > news >正文

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. 首次访问受保护资源
  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)直接访问资源。
UserApp (CAS Client)CAS ServerDB/LDAP (认证源)访问受保护资源(未登录)检测到未登录,重定向至CAS ServerURL: https://cas.example.com/login?service=http://app.example.com/cas/validate输入用户名/密码提交验证用户凭证返回验证结果(成功/失败)生成TGT(服务器存储)和TGC(写入浏览器Cookie)基于TGT生成一次性ST重定向回App,携带STURL: http://app.example.com/cas/validate?ticket=ST-123携带ST访问客户端调用/serviceValidate接口验证ST请求: https://cas.example.com/serviceValidate?service=...&ticket=ST-123检查ST有效性(关联TGT、未过期、未重复使用)返回验证结果(含用户名等信息)创建本地会话(JSESSIONID)允许访问资源显示登录失败页面alt[验证成功][验证失败]UserApp (CAS Client)CAS ServerDB/LDAP (认证源)
2. 二次访问与跨系统访问
  • 二次访问:用户再次访问同一应用时,客户端通过Cookie中的JSESSIONID获取本地会话,直接放行请求,无需重复认证。
  • 跨系统访问:用户访问另一应用(如http://mail.example.com),该应用的CAS Client检测到未登录,重定向至CAS Server。此时浏览器携带TGC,CAS Server根据TGC找到对应TGT,生成新的ST并返回给新应用,实现单点登录。

跨系统访问(已登录)流程图:

UserApp1 (已登录)App2 (CAS Client)CAS Server访问App2受保护资源(未登录)检测到未登录,重定向至CAS ServerURL: https://cas.example.com/login?service=http://app2.example.com/cas/validate携带TGC(浏览器Cookie)访问CAS Server用TGC查询TGT(验证有效性)基于TGT生成新ST(ST-456)重定向回App2,携带ST-456URL: http://app2.example.com/cas/validate?ticket=ST-456携带ST-456访问验证ST-456验证通过,返回用户信息创建本地会话允许访问资源跳转至登录页面,要求重新登录alt[TGT有效][TGT失效(过期/销毁)]UserApp1 (已登录)App2 (CAS Client)CAS Server
三、核心原理:票据机制与安全设计

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,防止票据在传输中被窃取。
http://www.dtcms.com/a/272589.html

相关文章:

  • 【前端】【Echarts】ECharts 词云图(WordCloud)教学详解
  • Prompt提示词的主要类型和核心原则
  • 在vscode中和obsidian中使用Mermaid
  • Spring AI Alibaba(2)——通过Graph实现工作流
  • Flutter 与 Android 的互通几种方式
  • Linux 中 sed 命令
  • RedisJSON 路径语法深度解析与实战
  • Spring Boot + Javacv-platform:解锁音视频处理的多元场景
  • 【TCP/IP】12. 文件传输协议
  • MySQL索引操作全指南:创建、查看、优化
  • Debian-10编译安装Mysql-5.7.44 笔记250706
  • macOS 上安装 Miniconda + Conda-Forge
  • Jekyll + Chirpy + GitHub Pages 搭建博客
  • 如何使用Java WebSocket API实现客户端和服务器端的通信?
  • 蓝桥杯第十六届(2025)真题深度解析:思路复盘与代码实战
  • MinerU将PDF转成md文件,并分拣图片
  • Alibaba Druid主要配置
  • 图片合并pdf
  • 新手向:实现ATM模拟系统
  • TDengine 数据库建模最佳实践
  • Oracle 视图
  • Tomcat:Java Web应用的幕后英雄
  • 线性探针是什么:是一种用于探测神经网络中特定特征的工具
  • 从零开始搭建深度学习大厦系列-3.卷积神经网络基础(5-9)
  • 李宏毅(深度学习)--(2)
  • 数据库复合索引设计:为什么等值查询列应该放在范围查询列前面?
  • 区间动态规划详解
  • 【JMeter】跨线程组传递参数
  • 在Docker中运行macOS的超方便体验!
  • SpringAI×Ollama:Java生态无缝集成本地大模型实践指南