首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

单点登录SSO的介绍和CAS+选型(2)

单点登录SSO的介绍和CAS+选型(2)

CAS相关词汇和概念

(后面代码小节会详细介绍,这里初步了解即可)

TGC(ticket-granting cookie)-- ------- 授权的票据证明,由 CAS Server 通过 SSL 方式发送给终端用户;

KDC( Key Distribution Center ) ---------- 密钥发放中心;

ST (Service ticket) --------- 服务票据, 由 KDC 的 TGS 发放, ST   只能被尝试验证一次。 任何一台 Workstation 都需要拥有一张有效的 Service Ticket 才能访问域内部的应用 (Applications) 。 如果能正确接收 Service Ticket ,说明在 CASClient-CASServer 之间的信任关系已经被正确建立起来,通常为一张数字加密的证书;

Ticket Granting tieckt(TGT) --------- 票据授权票据,由 KDC 的 AS 发放。即获取这样一张票据后,以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交 Credentials (凭证或身份认证信息 ) ;

Authentication Service (AS) --------- 认证服务,索取 Crendential ,发放 TGT ;

Ticket-Granting Service (TGS) --------- 票据授权服务,索取 TGT ,发放 ST 。




CAS协议和工作流程

下图是 CAS 最基础协议:


1 、 CAS Client 与受保护的客户端应用部署在一起,以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求, CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket ( ST )和 Ticket Granting tieckt(TGT) ,如果没有,则说明当前用户尚未登录,于是将请求重定向到指定好的 CAS Server 登录地址,并传递 Service (也就是要访问的目的资源地址),以便登录成功过后转回该地址。用户在第 3 步中输入认证信息,如果登录成功, CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ,并缓存以待将来验证,之后系统自动重定向到 Service 所在地址,并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ), CAS Client 在拿到 Service 和新产生的 Ticket 过后,在第 5 , 6 步中与 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。

2 、在该协议中,所有与 CAS 的交互均采用 SSL 协议确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。

3 、 CAS 如何实现 SSO

当用户访问另一服务再次被重定向到 CAS Server 的时候, CAS Server 会主动获到这个 TGC cookie ,然后做下面的事情:

1) 如果 User 的持有 TGC 且其还没失效,那么就走基础协议图的 Step4 ,达到了 SSO 的效果;

2) 如果 TGC 失效,那么用户还是要重新认证 ( 走基础协议图的 Step3) 。



另外,CAS 协议中还提供了 Proxy (代理)模式,以适应更加高级、复杂的应用场景,具体介绍可以参考 CAS 官方网站上的相关文档。




cas的验证流程

1.      用户浏览受系统保护的URL。

2.      CAS Client服务端收到请求,Filter拦截该请求,在Filter中判断该用户是否已经登陆,如果已经登陆,就直接进入系统,否则,将请求转发到CAS Server服务端的LoginURL。

3.      在LoginURL中会获取到用户的Cookie,检验用户是否已经在其他相关使用SSO的系统登陆成功。如果已经在其他的系统登陆了,则将请求转回 CAS Client,并且带回一个ticket, CAS Client再次发送请求到ValidateURL。否则,系统提示用户输入ID和PASSWORD。

4.      提交后请求到ValidateURL,CAS Server验证ticket的有效性。然后返回结果给CAS Client。如果ticket有效,则CAS Client应让该用户浏览受保护的资源。否则,重定向到登陆页面,提示用户输入ID和PASSWORD。

5.      校验ID和Password是否匹配。如不匹配,再次要求用户输入ID和PASSWORD。否则,CAS Server记录用户登陆成功。并向浏览器回送Cookie,记录用户已经登陆成功。如果浏览器不支持Cookie,则无法实现单点登陆。
返回列表