SSO之CAS

单点登录SSO

? 单点登录的主要原理就是在每次登录成功以后生成一个唯一不可重复的令牌 token，我们就简单的用了一个随

机的 UUID 来生成 token。当用户登录成功后用生成的 token 做 key， 登录的用户对象信息转成 json 字符串后作

为 value 放到 redis 里边【使用的是 hash 这种数据结构】。然后再把这个 token 回写给浏览器的 cookie 中。这

样，当别的模块再访问后台的时候只需要将 cookie 中的 token 传给服务端，服务端就能根据 token 到 Redis 中获

取用户信息，如果能获取到说明登录过，如果获取不到说明没有登录过，从而实现单点登录的功能。

? 再来说一下 cookie 保存时的一些细节。 因为我们的系统在部署时，各个模块都是通过 Nginx 映射到同一个

一级域名下的， cookie 只要把他的作用域设置成一级域名，就可以在所有同一个一级域名下的模块中共享。所以

我们以字符串 “sso”为 key 把随机生成的 token 为 value 写入到 cookie 里边，设置有效期 30 分钟；

? 然后做了一个统一校验 token 的接口；各个模块在自己的拦截器里边，调用此 token 校验接口，验证是否登

录。统一校验 token 的接口的主要流程是，首先从 cookie 里边获取到 token，然后通过 token 到 redis 里边获取

用户信息。这两个过程，任何一个失败，都直接返回 null， 则说明没有登录，拦截到统一的登录页面，并把进入

拦截到的 url 放入 cookie 里边，方便登录成功以后获取这个 url，进行原路径跳转，而不是每次登录都进入首页，

提高用户的体验度。 如果成功，就 cookie 和 token 的值从新设置一遍(这个是为了刷新有效期)；这样就实现了多

个模块只需要登录一次就可以的流程。

简单来说：

SSO就像是去迪士尼游玩，只需要在购票处购买一次票，进到里面就可以随便玩。

怎么才能做到只需购买一次票，就可以到处通行呢？这时候就有了CAS，CAS就是SSO的一个解决方案

CAS

? CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法， CAS 在 2004

年 12 月正式成为 JA-SIG 的一个项目。 CAS 具有以下特点：

【1】 开源的企业级单点登录解决方案。

【2】 CAS Server 为需要独立部署的 Web 应用。

【3】 CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用，包括 Java, .Net, PHP, Perl,

Apache, uPortal, Ruby 等。

? 从结构上看， CAS 包含两个部分： CAS Server 和 CAS Client。

CAS Server 需要独立部署，主要负责对用户的认证工作，就像是把第一次登录用户的一个标识存到这里，以便此

用户在其他系统登录时验证其需不需要再次登录；

CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server，当用户访问我们的应

用时，首先需要重定向到CAS Server端机型验证，要是原来登录过，就免去登录，重定向到下游系统，否则进行

用户名密码登录操作。

下图是CAS 最基本的协议过程：

SSO 单点登录访问流程主要有以下步骤：

1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
3. 用户认证：用户身份认证。
4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket。
5. 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务。
6. 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。

CAS相关术语

• Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在server端

• Ticket-granting cookie (TGC) ：其实就是一个cookie，存放用户身份信息，由server发给client端

• Service ticket (ST) ：由TGT生成的一次性票据，用于验证，只能用一次。相当于server发给client一张票，然

  后client拿着这是个票再来找server验证，看看是不是server签发的。就像是我给了你一张我的照片，然后你

  拿照片再来问我，这个照片是不是你。。。没错，就是这么无聊