SSO 仅仅是一种架构,一种设计,而 CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然,除了 CAS 之外,实现 SSO 还有其他手段,比如简单的 cookie。
CAS (Central Authentication Service)中心授权服务,本身是一个开源协议,分为 1.0 版本和 2.0 版本。1.0 称为基础模式,2.0称为代理模式,适用于存在非 Web 应用之间的单点登录。本文只涉及 CAS 1.0,
主要角色
1、 User (多个)
2、 Web 应用(多个)
3、 SSO 认证中心( 1个)
实现模式的原则
SSO 实现模式一般包括以下三个原则:
1、 所有的认证登录都在 SSO 认证中心进行;
2、 SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户;
3、 SSO 认证中心和所有的 Web 应用建立一种信任关系,也就是说 web 应用必须信任认证中心。(单点信任)
CAS 基本原理
结构
CAS分为两部分,CAS Server和CAS Client
1 | CAS Server用来负责用户的认证工作,就像是把第一次登录用户的一个标识存在这里,以便此用户在其他系统登录时验证其需不需要再次登录。 |
术语
1 | Ticket Granting ticket (TGT) :可以认为是CAS Server根据用户名密码生成的一张票,存在server端 |
基础协议图
如上图: 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 Server 的时候, CAS Server 会主动获到这个 TGC cookie ,然后做下面的事情:
如果 User 持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果;
如果 TGC 失效,那么用户还是要重新认证 ( 走基础协议图的 Step3) 。
CAS 安全性
CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。
TGC/PGT安全性
对于一个 CAS 用户来说,最重要是要保护它的 TGC ,如果 TGC 不慎被 CAS Server 以外的实体获得, Hacker 能够找到该 TGC ,然后冒充 CAS 用户访问 所有授权资源。 PGT 的角色跟 TGC 是一样的。
从基础模式可以看出, TGC 是 CAS Server 通过 SSL 方式发送给终端用户,因此,要截取 TGC 难度非常大,从而确保 CAS 的安全性。
TGT 的存活周期默认为 120 分钟
ST/PT安全性
ST ( Service Ticket )是通过 Http 传送的,因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全(事实上都是可以配置的):
1、 ST 只能使用一次
CAS 协议规定,无论 Service Ticket 验证是否成功, CAS Server 都会清除服务端缓存中的该Ticket ,从而可以确保一个 Service Ticket 不被使用两次。
2、 ST 在一段时间内失效
CAS 规定 ST 只能存活一定的时间,然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
3、 ST 是基于随机数生成的
ST 必须足够随机,如果 ST 生成规则被猜出, Hacker 就等于绕过 CAS 认证,直接访问 对应的服务。
CAS和SSO关系
SSO 仅仅是一种架构,一种设计,而CAS 则是实现 SSO 的一种手段。两者是抽象与具体的关系。当然,除了 CAS 之外,实现 SSO 还有其他手段,比如简单的 cookie。
TGC什么用?
TGT:Ticket Grangting Ticket
TGT 是 CAS 为用户签发的登录票据,拥有了 TGT,用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时,CAS 以此 Cookie 值(TGC)为 key 查询缓存中有无 TGT ,如果有的话,则相信用户已登录过。达到cas server的二次免登效果。
如果没有的话:首次登录子系统A时,重定向到cas server用户名密码认证一次,再次登录到子系统B时,还需要再次,重定向到cas server用户名密码认证二次。和初衷背离。
登出
用户在一个系统登出了,访问其它子系统,也应该是登出状态。要想做到这一点,应用除结束本地局部会话外,还应该通知认证中心该用户登出。
认证中心接到登出通知,即可结束全局会话,同时需要通知所有已建立局部会话的子系统,将它们的局部会话销毁。这样,用户访问其它应用时,都显示已登出状态。
整个登出流程如下:
1)、客户端向应用A发送登出Logout请求。
2)、应用A取消本地会话,同时通知认证中心,用户已登出。
3)、应用A返回客户端登出请求。
4)、认证中心通知所有用户登录访问的应用,用户已登出(通过删除对应用户sesson实现)。
登录B系统,认证中心是如何判断用户已经登录的?
答:在系统A登录成功后,用户和认证中心之间建立起了全局会话,这个全局会话就是TGT(Ticket Granting Ticket),TGT位于CAS服务器端。
用户发送登录系统B的请求,首先会去Cookie中拿JSESSION,因为系统B并未登录过,session会话还未创建,JSESSION的值是拿不到的,然后将请求重定向到CAS认证中心,CAS认证中心先去用户浏览器中拿TGC的值,也就是全局会话id,如果存在则代表用户在认证中心已经登录,附带上认证令牌重定向到系统B。
登出的过程,各个系统对当前用户都做了什么?
答:认证中心清除当前用户的全局会话TGT,同时清掉cookie中TGT的id:TGC;
然后是各个客户端系统,比如系统A、系统B,清除局部会话session,同时清掉cookie中session会话id:jsession
参考
一篇文章彻底弄懂CAS实现SSO单点登录原理:https://www.cnblogs.com/wangsongbai/p/10299655.html
基于CAS实现SSO单点登录:https://zhuanlan.zhihu.com/p/25007591
单点登录(SSO)看这一篇就够了:https://www.jianshu.com/p/75edcc05acfd
cas单点登录认证原理:https://www.cnblogs.com/tudou1223/p/9018423.html
认证鉴权系列
http认证鉴权01基本认证和摘要认证
http认证鉴权02同域SSO
http认证鉴权03跨域SSO之CAS
http认证鉴权04跨域SSO之OAuth2入门
http认证鉴权05CAS和OAuth2区别
http认证鉴权06CSRF跨站请求伪造