「千锋大数据开发学院」CAS实现SSO 单点登录原理( 二 )


3. CAS 的基本原理
3.1. 结构体系
从结构体系看 ,CAS 包括两部分: CAS Server 和 CAS Client。
3.1.1. CAS Server
CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials)。
3.1.2. CAS Client
负责处理对客户端受保护资源的访问请求 , 需要对请求方进行身份认证时 , 重定向到 CAS Server 进行认证 。 (原则上 , 客户端应用不再接受任何的用户名密码等 Credentials ) 。
CAS Client 与受保护的客户端应用部署在一起 , 以 Filter 方式保护受保护的资源 。
3.2. CAS 原理和协议
3.2.1. 基础模式
基础模式 SSO 访问流程主要有以下步骤:
访问服务: SSO 客户端发送请求访问应用系统提供的服务资源 。
定向认证: SSO 客户端会重定向用户请求到 SSO 服务器 。
用户认证:用户身份认证 。
发放票据: SSO 服务器会产生一个随机的 Service Ticket。
验证票据: SSO 服务器验证票据 Service Ticket 的合法性 , 验证通过后 , 允许客户端访问服务 。
传输用户信息: SSO 服务器验证票据通过后 , 传输用户认证结果信息给客户端 。
下面是 CAS 最基本的协议过程:
「千锋大数据开发学院」CAS实现SSO 单点登录原理
本文插图
CAS实现SSO单点登录原理
基础协议图
如 上图: CAS Client 与受保护的客户端应用部署在一起 , 以 Filter 方式保护 Web 应用的受保护资源 , 过滤从客户端过来的每一个 Web 请求 , 同 时 ,CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket), 如果没有 , 则说明该用户是没有经过认证的;于是 CAS Client 会重定向用户请求到 CAS Server ( Step 2 ) , 并传递 Service (要访问的目的资源地址) 。Step 3 是用户认证过程 , 如果用户提供了正确的 Credentials,CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket, 并缓存以待将来验证 , 并且重定向用户到 Service 所在地址(附带刚才产生的 Service Ticket ) , **并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ) **; CAS Client 在拿到 Service 和新产生的 Ticket 过后 , 在 Step 5 和 Step6 中与 CAS Server 进行身份核实 , 以确保 Service Ticket 的合法性 。
在该协议中 , 所有与 CAS Server 的交互均采用 SSL 协议 , 以确保 ST 和 TGC 的安全性 。 协议工作过程中会有 **2 次重定向 **的过程 。 但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的(使用 HttpsURLConnection ) 。
CAS 请求认证时序图如下:
「千锋大数据开发学院」CAS实现SSO 单点登录原理
本文插图
CAS实现SSO单点登录原理
3.2.1. CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候 ,CAS Server 会主动获到这个 TGC cookie, 然后做下面的事情:
如果 User 持有 TGC 且其还没失效 , 那么就走基础协议图的 Step4, 达到了 SSO 的效果;
如果 TGC 失效 , 那么用户还是要重新认证 ( 走基础协议图的 Step3)。
3.2.2. CAS 代理模式
该模式形式为用户访问 App1,App1 又依赖于 App2 来获取一些信息 , 如: User --App1 --App2 。
这 种情况下 , 假设 App2 也是需要对 User 进行身份验证才能访问 , 那么 , 为了不影响用户体验(过多的重定向导致 User 的 IE 窗口不停地 闪动 ),CAS 引入了一种 Proxy 认证机制 , 即 CAS Client 可以代理用户去访问其它 Web 应用 。
代 理的前提是需要 CAS Client 拥有用户的身份信息 ( 类似凭据 )。 之前我们提到的 TGC 是用户持有对自己身份信息的一种凭据 , 这里的 PGT 就是 CAS Client 端持有的对用户身份信息的一种凭据 。 凭借TGC,User 可以免去输入密码以获取访问其它服务的 Service Ticket, 所以 , 这里凭借 PGT,Web应用可以代理用户去实现后端的认证 , 而 **无需前端用户的参与 ** 。


推荐阅读