SSO (Single Sign On)

avatar

单点登录：它把两个及以上个产品中的用户登录逻辑抽离出来，达到只输入一次用户名密码，就能同时登录多个产品的效果
优点：

  • 提升用户体验，避免多次登录不同的应用
  • 避免重复开发，避免开发多套登录逻辑
  • 提升安全系数，快速修复

同域 SSO

工作流：

  • 登录认证成功，服务器把用户的登录信息写入 session
  • 服务器为该用户生成一个 cookie，并加入到 response header 中，随着请求返回而写入浏览器。该 cookie 的域设定为 dxy.cn。
  • 下一次，当用户访问同域名的产品 dxy.cn/b 时，由于 a 和 b 在同一域名下，也是 dxy.cn，浏览器会自动带上之前的 cookie。此时后台服务器就可以通过该 cookie 来验证登录状态了

同父域 SSO

同父域 SSO 是同域 SSO 的简单升级，唯一的不同在于，服务器在返回 cookie 的时候，要把 cookie 的 domain 设置为其父域。

比如两个产品的地址分别为 a.dxy.cn 和 b.dxy.cn，那么 cookie 的域设置为 dxy.cn 即可。在访问 a 和 b 时，这个 cookie 都能发送到服务器，本质上和同域 SSO 没有区别。

跨域 SSO（CAS）

在上面两种情况下，我们都没有专门设置 SSO 服务器。但是当两个产品不同域时，cookie 无法共享，所以我们必须设置独立的 SSO 服务器了。这个时候，我们就是通过标准的 CAS 方案来实现 SSO 的 CAS

CAS （Central Authentication Service）中心授权服务

面向 Web 企业单点登录解决方案，CAS 则是实现 SSO 的一种手段，跨域 SSO 登录

本身是一个开源协议，分为 1.0 版本

术语

  • Client：用户
  • Server：中心服务器，也是 SSO 中负责单点登录的服务器
  • Service：需要使用单点登录的各个服务，相当于上文中的产品 a/b
  • 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 验证，验证通过后，允许用户访问资源

票据关系：

workflow

工作流：

  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（sso.dxy.cn/login 域名下写入的 cookie），这个 cookie 代表用户在 SSO 中的登录状态，它的值就是 TGC。
  1. 浏览器重定向到产品 a。此时重定向的 url 中携带着 SSO 服务器生成的 ST
  2. 根据 ST，a 服务器向 SSO 服务器发送请求，SSO 服务器验证票据的有效性。验证成功后，a 服务器知道用户已经在 sso 登录了，于是 a 服务器构建用户登录 session，记为 a session。并将 cookie 写入浏览器（www.a.cn 域名下写入的 cookie）。注意，此处的 cookie 和 session 保存的是用户在 a 服务器的登录状态，和 CAS 无关。
  3. 用户访问产品 b，域名是 www.b.cn。
  4. 由于用户没有携带在 b 服务器上登录的 b cookie，所以 b 服务器返回 http 重定向，重定向的 url 是 SSO 服务器的地址，去询问用户在 SSO 中的登录状态。
  5. 浏览器重定向到 SSO。注意，第 4 步中已经向浏览器写入了携带 TGC 的 cookie，所以此时 SSO 服务器可以拿到，根据 TGC 去查找 TGT，如果找到，就判断用户已经在 sso 登录过了
  6. SSO 服务器返回一个重定向，重定向携带 ST。注意，这里的 ST 和第 4 步中的 ST 是不一样的，事实上，每次生成的 ST 都是不一样的
  7. 浏览器带 ST 重定向到 b 服务器，和第 5 步一样
  8. b 服务器根据票据向 SSO 服务器发送请求，票据验证通过后，b 服务器知道用户已经在 sso 登录了，于是生成 b session，向浏览器写入 b cookie
  9. 之后当用户访问 a 或者 b 后，直接会携带 a cookie/b cookie，就不用再向 SSO 确认了。
avatar
文章
阅读
粉丝