CAS单点登录

CAS （Central Authentication Service）

• 用户在 CAS 服务端录入用户名和密码之后通过 Ticket 在不同系统间进行认证
• 一个 CAS Server，多个 CAS Client（需要认证的 Web 应用）

CAS术语

• TGT（Ticket Granting ticket）
  • 作为认证中心的全局会话
  • CAS Server根据用户名密码生成的一张票，存在CAS服务端，TGT并未存放在Session中
• TGC（Ticket-Granting cookie）
  • 其实就是一个Cookie，存放用户身份信息，由Server发给Client端
  • 存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证
  • TGC(Ticket Granting Cookie)存放了TGT的id,保存在用户浏览器上，
  • CAS认证中心先去用户浏览器中拿TGC的值，也就是全局会话id
  • 如果存在则代表用户在认证中心已经登录，附带上认证令牌重定向到服务，然后服务建立局部会话
• Service
  • 在CAS系统中，接入的各个子系统叫服务
• PGT（proxy granting ticket），代理模式下的TGT
• ST（Service ticket）
  • CAS为用户签发的访问某一service的票据，ST是TGT签发的
• PT（proxy ticket），代理模式下的ST

CAS单点登录原理

• 参与者 CAS Server、CAS Client（需要认证的 Web 应用）、客户端浏览器
• 真实登录操作在 CAS Server（登录中心）实现，客户端 Web 应用通过 Ticket 进行登录状态验证，验证通过后各自设置 Session 完成各自系统的认证
• 用户登录，Web 应用 A 会将认证请求重定向到 CAS Server，同时在客户端写入一个 Cookie（应为TGC）
• 应用未认证操作时， CAS Server 会通过带有 Ticket 的回调地址重定向回 Web 应用 A，web应用带ticket校验，校验成功废弃ticket,返回用户信息。应用基于用户信息和一开始写入的cookie（含全局TGT的id）设置session（CAS服务局部状态）。
• 用户退出
  • 从 Web 应用 A 发起退出请求，会在 A 系统先退出，然后将告知 CAS Server 用户退出
  • CAS Server 会在服务端（登录中心）将该用户退出，并且将退出消息告知其它子系统
  • 其它子系统再各自完成退出操作，达到所有系统的用户退出操作

关键点

• CAS Client(web应用)端负责与CAS Server 进行ticket验证交互
• 客户端浏览器通过web应用（目的在于写cookie设置session）间接向CAS Server进行用户认证
• 整个过程中，子系统与 CAS 服务端之间的交互通常均采用 SSL 协议（HTTPS）
• 认证与登录相关，一般通过数据库进行匹配，每次与服务器通信都会有自己的局部会话
• 全局/局部会话
  • 用户到认证中心登录后，用户和认证中心之间建立起了会话称之为全局会话
  • 系统应用（CAS服务）和用户浏览器之间建立起局部会话
  • 用户访问应用时，首先判断局部会话是否存在，不存在，就重定向到认证中心判断全局会话是否存在。存在，则就不用去认证中心验证
  • 通过TGC能判断用户是否登录（认证），但切换CAS服务后，并不能直接获取用户信息

小结

• CAS是cookie记住密码的高级版，只不过记住的信息方换成了CAS客户端，且记住的内容只是用户登录注册过CAS服务端的用户标识信息，比如uid。
• CAS服务端至少做了两次认证，一次是用户发起的账号密码形式登录，返回的TGC存储在浏览器cookie中，第二次则是CAS客户端发起的，拿着间接获取的ST（一次性）及之前得到的TGC，到服务端获取用户完整信息。