基于CAS实现单点登录(SSO):工作原理

 

单点登录(SingleSign On , 简称 SSO )是目前比较流行的服务于企业业务整合的解决方案之一, SSO使得在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

 

SSO的解决方案很多,比如收费的有UTrust、惠普灵动等,开源的有CASSmart SSO等,其中应用最为广泛的是CAS

 

CAS 介绍

CAS(CentralAuthentication Service)是一款不错的针对 Web 应用的单点登录框架。

CAS从结构上看包括两部分,CAS Server 为需要独立部署的 Web应用,CAS Client 为非常多的客户端提供支持,这个客户端指单点登录系统中的各个 Web 应用,包括 Java, .Net, PHP, Perl,Apache, uPortal, Ruby 等。

 

CAS 原理和协议

CAS Server需要独立部署,主要负责对用户的认证工作;

CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。图是 CAS最基本的协议过程:


CAS Client 与受保护的客户端应用部署在一起,以 Filter方式保护受保护的资源。对于访问受保护资源的每个 Web 请求,CAS Client 会分析该请求的 Http 请求中是否包含 ServiceTicket(服务票据,由 CASServer发出用于标识目标服务)

 

如果没有,则说明当前用户尚未登录,于是将请求重定向到指定好的 CAS Server 登录地址,并传递 Service(也就是要访问的目的资源地址),以便登录成功过后转回该地址。

如果有,则说明当前用户已经登录,直接访问目的资源地址。

 

用户输入认证信息,如果登录成功,CAS Server 随机产生一个相当长度、唯一、不可伪造的 ServiceTicket,并缓存以待将来验证,之后系统自动重定向到 Service 所在地址,并为客户端浏览器设置一个 Ticket GrantedCookie(CAS会话标识)

 

CAS Client 在拿到 Service 和新产生的 Ticket 过后,在第 5,6 步中与 CAS Server进行身份合适,以确保 Service Ticket 的合法性。

 

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

 

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

 

了解CAS工作原理后,接下来会进行单点登录的实例演示。


发布了130 篇原创文章 · 获赞 433 · 访问量 45万+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章