简介
Cas介绍
CAS ( Central Authentication Service ),最初由耶鲁大学的Shawn Bayern 开发,后由Jasig社区维护,经过十多年发展,目前已成为影响最大、广泛使用的、基于Java实现的、开源SSO解决方案。cas旨在为 Web 应用系统提供一种可靠的单点登录解决方法(属于 Web SSO )。 CAS 开始于 2001 年, 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。
CAS的官方网址是: https://www.apereo.org/projects/cas
工程代码网址:https://github.com/Jasig/cas
架构
CAS应用的整体架构官方提供了一个比较清晰的架构图,如下所示:
从结构体系看, CAS 包括两部分: CAS Server 和 CAS Client 。
CAS Server
CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。
CAS Client
负责处理对客户端受保护资源的访问请求,需要对请求方进行身份认证时,重定向到 CAS Server 进行认证。(原则上,客户端应用不再接受任何的用户名密码等 Credentials )。
CAS Client 与受保护的客户端应用部署在一起,以 Filter 方式保护受保护的资源。
主要特性
SSO英文全称Single Sign On,单点登录。SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
一般场景下,我们不需要重新造轮子,直接在成熟技术框架基础上开发使用即可。这也是CAS在很多互联网和企业应用中广泛使用的原因。当然,对于某些场景,如安全性因素、扫码登录、更特殊更高效的应用场景,在技术实力许可的情况下,通常都自己实现SSO,当然,也可以自定义CAS。
我粗略的罗列一些CAS的优势:
1、 开源的、多协议的 SSO 解决方案; Protocols : Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多种认证机制: Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等,可自定义;
3、 安全策略:使用票据( Ticket )来实现支持的认证协议;
4、 支持授权:可以决定哪些服务可以请求和验证服务票据( Service Ticket );
5、 提 供高可用性:通过把认证过的状态数据存储在 TicketRegistry 组件中,这些组件有很多支持分布式环境的实现, 如: BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等;
6、 支持多种客户端: Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
单点登录流程概述
协议过程
如 上图: 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 Server认证中心去登录。登录成功后,认证中心会产生一个票据叫TGT(Ticket Granting Ticket),TGT即代表了用户与认证中心直接的全局会话。TGT存在,表明该用户处于登录状态。
TGT并没有放在Session中,也就是说,CAS全局会话的实现并没有直接使用Session机制,而是利用了Cookie自己实现的,这个Cookie叫做TGC(Ticket Granting Cookie),它存放了TGT的id,认证中心服务端实现了TGT。
在认证中心登录下,看下登录前后cookie的变化。显然,在登录后,多出一个叫CASTGC的Cookie,它来维持全局会话。
如果是应用系统登录,客户端会被引导到认证中心进行登录,登录成功后再重定向回应用系统,这时会带上一个登录令牌,告知系统应用登录成功。
这个令牌,在CAS中叫做ST(Service Ticket)服务票据,它的作用和Nebula的token类似。当然,和Nebula一样,应用系统收到ST后,会直接向CAS Server去验证,验证通过后,应用系统即可建立本地会话,返回用户访问的受限资源。
其中第一个,我们看到,登录成功后,系统会设置CASTGC Cookie,同时重定向回应用时带上了一个ticket变量,这个就是ST。
一个cookie, N个session
CAS 的 SSO 实现方式可简化理解为: 1 个 Cookie 和 N 个 Session 。 CAS Server 创建 cookie,在所有应用认证时使用,各应用通过创建各自的 Session 来标识用户是否已登录。
用 户在一个应用验证通过后,以后用户在同一浏览器里访问此应用时,客户端应用中的过滤器会在 session 里读取到用户信息,所以就不会去 CAS Server 认证。如果在此浏览器里访问别的 web 应用时,客户端应用中的过滤器在 session 里读取不到用户信息,就会去 CAS Server 的 login 接口认证,但这时CAS Server 会读取到浏览器传来的 cookie ( TGC ),所以 CAS Server 不会要求用户去登录页面登录,只是会根据 service 参数生成一个 Ticket ,然后再和 web 应用做一个验 证 ticket 的交互而已。
TGC: 处于cas.example.com域名下的cookie. CAS server在用户账密登录校验通过后会在该域名下设置TGC, 其他应用登录时会携带TGC. TGC是全局cookie.
JSESSIONID: 处于app1.example.com域名下的cookie, app1(CAS Client)在向CAS Server校验ST通过后在该域名下设置cookie, 后续访问app1携带该cookie. 每个app有对应的JSESSIONID.
术语解释
TGC:Ticket Granting Cookie
CAS 会将生成的 TGT 放在 session 中,而 TGC 就是这个 session 的唯一标识(sessionId),可以认为是 TGT 的key,为 TGT 就是 TGC 的 value,TGC 以 cookie 的形式保存在浏览器中,每个请求都会尝试携带 TGC。(每个服务都会在 session 和 cookie 中保存对应的 TGT 和 TGC)
TGT:Ticket Granting Ticket
TGT 是CAS 为用户签发的登录 ticket,也是用于验证用户登录成功的唯一方式。 TGT 封装了 Cookie 值以及 Cookie 值对应的用户信息,CAS 通过 Cookie 值(TGC)为 key 查询缓存中有无 TGT(TGC:TGT(key:value)),如果有的话就说明用户已经登录成。
ST:Service Ticket
服务票据,服务的惟一标识码 , 由 CAS Server 发出( Http 传送),通过客户端浏览器到达业务服务器端;一个特定的服务只能有一个惟一的 ST ;