单点登录(二)——CAS 单点登录



  • 实现单点登录可采用的策略

    实现单点登录可以采用的方式大多有以下几种:

    1. 利用成熟的软件框架(CAS,OPENAM 等)

    2. 自己建设单点登录框架(像sohu的单点登录)

    3. 最简单的使用 URL 模拟登录

    据统计,大概每 10 个采用开源构建 Web SSO 的 Java 项目,就有 8 个使用 CAS。因为 CAS 是单点登录最简单实效,而且足够安全的单点登录实现方式的选择。这里重点介绍一下 CAS 登录框架以及它改进了普通 SSO 单点登录中存在的哪些问题。

    普通 SSO 单点登录的不足

    1. 不能适应复杂的业务系统

      普通单点登录仅考虑用户作为 SSO 访问者的情况,而忽视了业务系统作为 SSO 访问者的时候应该怎么处理。我们探讨一种复杂的状况,即用户访问 helloservice,helloservice 又依赖于 helloservice2 来获取一些信息,假设 helloservice2 也是需要对 User 进行身份验证才能访问,那这样一来就会反复的进行重定向操作。尽管重定向的速度很快,但过多的重定向可能会导致浏览器窗口不停闪动,影响用户体验,效率也很低。

    2. 安全性问题

      普通单点登录是将 token 通过 URL 直接发送,这样会存在安全性的问题,就是我的 token 有可能直接就被黑客获取到。而在 SSO 单点登录模式中,直接向客户端发送带有 token 的请求时,客户端只会向统一认证中心核对 token 是否正确,这样以来只要我获得了 token 之后,就相当于我不用登录就可以直接进入客户端业务系统。并且一个 token 有时会同时给很多个业务系统授权,就表明我拿到一个 token 就可以同时进入许多个相关联的业务系统。

    3. 语言冲突问题

      多个客户端程序可能会用到多种语言进行开发,在解决不同语言冲突的问题时会导致开发者进行一些多余的操作。尤其是在单点登录系统集成多个已有的项目时,会给开发者造成极大的不方便。关于后端知识我具体了解不多,这里就先不细说。

    CAS框架

    CAS简介

    CAS全称为 Central Authentication Service 即中央认证服务,是一个企业多语言单点登录的解决方案,并努力去成为一个身份验证和授权需求的综合平台。

    CAS是由Yale大学发起的一个企业级的、开源的项目,旨在为Web应用系统提供一种可靠的单点登录解决方法(属于 Web SSO )。

    CAS协议至少涉及三方:客户端Web浏览器,请求身份验证的Web应用程序和CAS服务器。 它也可能涉及后端服务,如数据库服务器,它没有自己的HTTP接口,但与Web应用程序进行通信。

    CAS特点

    1. 多种的协议的支持,包括CAS (v1、v2、v3)、SAML(v1、v2)、OAuth、OpenID、OpenID Connect和WS-Federation Passive Requestor

    2. 多种认证机制,可以通过JAAS,LDAP,RDBMS,X.509,Radius,SPNEGO,JWT,Remote,Trusted,BASIC,Apache Shiro,MongoDB,Pac4J等进行身份验证

    3. 可以通过WS-FED,Facebook,Twitter,SAML IdP,OpenID,OpenID Connect,CAS等代理委派认证

    4. 多种形式的授权包括ABAC, Time/Date, REST, Internet2’s Grouper等

    5. 支持各种丰富的客户端,像常见的Java、Python、Node、PHP、C#、Perl等等

    6. 作为一个已经写好了的单点登录框架,可以直接对已有项目集成,使用方便

    CAS基本协议

    avatar

    上图是一个最基础的 CAS 协议, CAS Client 以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求,同时, CAS Client 会分析 HTTP 请求中是否包请求 Service Ticket,如果没有,则说明该用户是没有经过认证的,于是, CAS Client 会重定向用户请求到 CAS Server ( Step 2 )。 Step 3 是用户认证过程,如果用户提供了正确的认证信息, CAS Server 会产生一个随机的 Service Ticket ,然后,缓存该 Ticket ,并且重定向用户到 CAS Client (附带刚才产生的 Service Ticket ), Service Ticket 是不可以伪造的。最后, Step 5 和 Step6 是 CAS Client 和 CAS Server 之间完成了一个对用户的身份核实,用 Ticket 查到 Username ,因为 Ticket 是 CAS Server 产生的,因此,所以 CAS Server 的判断是毋庸置疑的。

    可以看到,CAS 的登录逻辑和普通 SSO 单点登录是没有很大区别的。

    CAS 术语解释

    1. TGT(Ticket Grangting Ticket)

      相当于普通单点登录模式中在认证中心服务端存储的 session,用于记录用户信息。当用户认证成功时,认证中心会设置浏览器的 cookie(即下面要说的 TGC),同时生成一个TGT对象,放入自己的缓存,TGT 对象的 ID 就是 cookie 的值。当 HTTP 再次请求到来时,如果传过来的有 CAS 生成的 cookie,则 CAS 以此 cookie 值为 key 查询缓存中有无 TGT ,如果有的话,则说明用户之前登录过,如果没有,则用户需要重新登录。

    2. TGC(Ticket Granting Cookie)

      相当于普通单点登录中认证中心发放的 cookie。TGC 为授权的票据证明,由 CAS Server 通过 SSL 方式发送给终端用户,是存放用户身份认证凭证的 cookie,在浏览器和CAS Server间通讯时使用,并且只能基于安全通道传输(Https),是CAS Server用来明确用户身份的凭证。

    3. ST(Service Ticket)

      相当于普通单点登录的 token。ST 是 CAS 为用户签发的访问某一系统的票据。用户访问系统时,系统发现用户没有 ST,则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求,如果用户的请求中包含 Cookie,则 CAS 会以此 Cookie 值为 key 查询缓存中有无 TGT,如果存在 TGT,则用此 TGT 签发一个 ST,返回给用户。用户凭借 ST 去访问 service,service 拿 ST 去 CAS 验证,验证通过后,允许用户访问资源。

    代理登录

    CAS 的代理登录就是解决了我们上面所说到的当一个业务系统需要从另一个业务系统获取资源时,需要重复进行重定向操作的不足。在代理模式中,当一个业务系统需要从另一个系统中获取资源时,该系统可以直接替代用户完成登录认证的过程。

    先看代理登录的过程:

    avatar

    与基本协议中的登录过程相比,代理登录过程在客户端向后台验证 ST 的同时向后台发送了一个额外的 PGTURL(而且是 SSL 的入口 )给 CAS 单点登录 Server 端,使得 CAS 单点登录 Server 端可以通过 PGTURL 提供一个 PGT 给 CAS 单点登录 Client 端。这里的 PGTURL 用于表示一个Proxy服务,是一个回调链接,PGT 相当于代理证书,PGTIOU 为取代理证书的钥匙,用来与 PGT 做关联关系。

    在完成代理服务器认证之后,就要去被代理客户端上去获取相关对应的应用资源。下面我们看一下具体的流程是怎么进行的:

    avatar

    从图中可以看到,代理登录的验证过程和普通的单点登录验证其实没有很大区别,只是进行验证的主体从用户变成了客户端。这样一来用户就可以在代理客户端中直接获取到受代理的业务系统中的资源,而不需要进行额外的登录操作。

    安全处理

    CAS 在安全方面的处理主要如下:

    1. CAS 传输的所有内容都是严格依赖于 SSL,即只能通过 https 进行传输。

    2. ST 的安全性:CAS 默认 ST 只能被使用一次,无论认证是否成功。在登录其他系统时统一认证中心会为你签发另一个不同的 ST,这就保证了即使 ST 被窃取到,也不能仅依靠 ST 就登录进多个系统。同时,ST 也存在有效期,一般为一个较小的时间段。

    结论

    就目前所学而言,在项目集成单点登录方面,还是推荐使用 CAS 单点登录框架。CAS 在原理上与普通单点登录没有较大的区别,但是其安全性和使用的便捷性都是更好的。


 

Copyright © 2018 bbs.dian.org.cn All rights reserved.

与 Dian 的连接断开,我们正在尝试重连,请耐心等待