CAS学习笔记（一）： 单点登录CAS的前端知识

概述

• 主要讲述cas服务端（认证中心）和cas客户端（子系统）如何利用cookie及session来判断用户是否已进行单点登录的过程

• 其中每个客户端未去cas服务端认证前，访问客户端其实都会经过浏览器重定向到认证中心的， 这样就会带上cas认证中心的用户cookie信息（当然只要认证过才有）了，验证用户签发的登录票据TGT是否已经拥有。因此， 客户端若未到cas认证中心认证过， 其实都会由浏览器重定向跳转到认证中心，如若已拥有TGT，则生成TS， 经由浏览器重定向回到客户端service

•  具体详见下文：

详解CAS

CAS 1.0 协议定义了一组术语，一组票据，一组接口。

下文用产品 a/b来表示cas客户端，即子系统。

 

术语：

• Client：用户。
• Server：中心服务器，也是 SSO 中负责单点登录的服务器。
• Service：需要使用单点登录的各个服务，相当于上文中的产品 a/b。

 

接口：

• /login：登录接口，用于登录到中心服务器。
• /logout：登出接口，用于从中心服务器登出。
• /validate：用于验证用户是否登录中心服务器。
• /serviceValidate：用于让各个 service 验证用户是否登录中心服务器。

 

票据

• TGT：Ticket Grangting Ticket 

TGT 是 CAS 为用户签发的登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时，CAS 以此 Cookie 值（TGC）为 key 查询缓存中有无 TGT ，如果有的话，则相信用户已登录过。

• TGC：Ticket Granting Cookie

CAS Server 生成TGT放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionId），以 Cookie 形式放到浏览器端，是 CAS Server 用来明确用户身份的凭证。

• ST：Service Ticket 

ST 是 CAS 为用户签发的访问某一 service 的票据。用户访问 service 时，service 发现用户没有 ST，则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求，CAS 发现用户有 TGT，则签发一个 ST，返回给用户。用户拿着 ST 去访问 service，service 拿 ST 去 CAS 验证，验证通过后，允许用户访问资源。

 

票据之间的关系如下图。注意，PGTIOU, PGT, PT 是 CAS 2.0 中的内容，感兴趣的同学可以自行了解。

 

详细步骤

看到这里，是不是又有点晕了？没关系，下面我们借助一个简单的场景，再来仔细捋一捋用 CAS 实现 SSO 的详细步骤，顺便加深理解之前提出的概念。

开始！

1. 用户访问产品 a，域名是 www.a.cn。
2. 由于用户没有携带在 a 服务器上登录的 a cookie，所以 a 服务器返回 http 重定向，重定向的 url 是 SSO 服务器的地址，同时 url 的 query 中通过参数指明登录成功后，回跳到 a 页面。重定向的url 形如 sso.dxy.cn/login?service=https%3A%2F%2Fwww.a.cn。
3. 由于用户没有携带在 SSO 服务器上登录的 TGC（看上面，票据之一），所以 SSO 服务器判断用户未登录，给用户显示统一登录界面。用户在 SSO 的页面上进行登录操作。
4. 登录成功后，SSO 服务器构建用户在 SSO 登录的 TGT（又一个票据），同时返回一个 http 重定向。这里注意：
   • 重定向地址为之前写在 query 里的 a 页面。
   • 重定向地址的 query 中包含 sso 服务器派发的 ST。
   • 重定向的 http response 中包含写 cookie 的 header。这个 cookie 代表用户在 SSO 中的登录状态，它的值就是 TGC。
5. 浏览器重定向到产品 a。此时重定向的 url 中携带着 SSO 服务器生成的 ST。
6. 根据 ST，a 服务器向 SSO 服务器发送请求，SSO 服务器验证票据的有效性。验证成功后，a 服务器知道用户已经在 sso 登录了，于是 a 服务器构建用户登录 session，记为 a session。并将 cookie 写入浏览器。注意，此处的 cookie 和 session 保存的是用户在 a 服务器的登录状态，和 CAS 无关。
7. 之后用户访问产品 b，域名是 www.b.cn。
8.  由于用户没有携带在 b 服务器上登录的 b cookie，所以 b 服务器返回 http 重定向，重定向的 url 是 SSO 服务器的地址，去询问用户在 SSO 中的登录状态。
9. 浏览器重定向到 SSO。注意，第 4 步中已经向浏览器写入了携带 TGC 的cookie，所以此时 SSO 服务器可以拿到，根据 TGC 去查找 TGT，如果找到，就判断用户已经在 sso 登录过了。
10. SSO 服务器返回一个重定向，重定向携带 ST。注意，这里的 ST 和第4步中的 ST 是不一样的，事实上，每次生成的 ST 都是不一样的。
11. 浏览器带 ST 重定向到 b 服务器，和第 5 步一样。
12. b 服务器根据票据向 SSO 服务器发送请求，票据验证通过后，b 服务器知道用户已经在 sso 登录了，于是生成 b session，向浏览器写入 b cookie。

 

如图所示，至此，整个登录流程结束。之后当用户访问 a 或者 b 后，直接会携带 a cookie/b cookie，就不用再向 SSO 确认了。

具体详见原文链接：https://juejin.im/post/5a002b536fb9a045132a1727

作者：丁香园F2E