CAS

CAS #

简介 #

集中式认证服务(英语:Central Authentication Service,缩写  CAS)是一种针对万维网单点登录协议。它的目的是允许一个用户访问多个应用程序,而只需提供一次凭证(如用户名和密码)。它还允许 web 应用程序在没有获得用户的安全凭据(如密码)的情况下对用户进行身份验证。“CAS” 也指实现了该协议的软件包。

CAS 是由耶鲁大学 的 Shawn Bayern 创始的,后来由耶鲁大学的 Drew Mazurek 维护。CAS1.0 实现了单点登录。 CAS2.0 引入了多级代理认证(Multi-tier proxy authentication)。CAS 其他几个版本已经有了新的功能。

2004 年 12 月,CAS 成为  Jasig(英语:Jasig)的一个项目,2008 年该组织负责 CAS 的维护和发展。CAS 原名 “耶鲁大学 CAS”,现在则被称为 “Jasig CAS”。

原理 #

Cas Server #

sequenceDiagram participant c as Client (The browser) participant ws as Web Server participant cs as CAS Server c->>ws: 访问网站地址 Note over ws: 尝试从 cookie 获取 pToken 和 sToken alt pToken 和 sToken 同时存在 ws-->>cs: /validate 验证合法性 alt 正常登录 cs-->>ws: 返回用户信息 ws->>c: 返回用户请求内容 else 不正常 cs-->>ws: 返回状态码 204 ws->>c: 返回重定向到 CAS 登录接口 Note over c, cs: 后面流程参考底下 Loop 循环 end else 不同时存在 ws->>c: 返回重定向到 CAS 登录接口 loop 访问 CAS 登录页面 c->>cs: 登录 alt 登录成功 cs->>c: 返回带 ticket 的重定向,并在浏览器写入 pToken 的 cookie c->>ws: 带有 ticket 的请求 ws-->>cs: 使用 ticket 置换 sToken alt 合法 ticket cs-->>ws: 返回 sToken ws->>c: 返回用户请求内容,并在浏览器写入 sToken 的 cookie else 非法 ticket ws->>c: 返回重定向到 CAS 登录接口 end else 登录失败 cs->>c: 返回错误提示页面 end end end

Session Server + Cas Server #

sequenceDiagram participant c as Client (The browser) participant ws as Web Server participant cs as CAS Server participant ss as Session Server c->>ws: 访问网站地址 Note over ws: 尝试从 cookie 获取 pToken 和 sToken alt pToken 和 sToken 同时存在 ws-->>ss: /validate 验证合法性 alt 正常登录 ss-->>ws: 返回用户信息 ws->>c: 返回用户请求内容 else 不正常 ss-->>ws: 返回状态码 204 ws->>c: 返回重定向到 CAS 登录接口 Note over c, ss: 后面流程参考底下 Loop 循环 end else 不同时存在 ws->>c: 返回重定向到 CAS 登录接口 loop 访问 CAS 登录页面 c->>cs: 登录 alt 登录成功 cs->>c: 返回带 ticket 的重定向,并在浏览器写入 pToken 的 cookie c->>ws: 带有 ticket 的请求 ws-->>cs: 使用 ticket 置换 sToken alt 合法 ticket cs-->>ws: 返回 sToken ws->>c: 返回用户请求内容,并在浏览器写入 sToken 的 cookie else 非法 ticket ws->>c: 返回重定向到 CAS 登录接口 end else 登录失败 ss->>c: 返回错误提示页面 end end end

百度 UUAP #

  1. 用户访问接入 uuap 的下游系统 xx.baidu.com,例如 family.baidu.com。

  2. 下游系统后端 server 从 cookie 中获取  pToken  及  sToken,校验是否同时存在,不同时存在直接重定向用户到  uuap 登录接口认证。

    pToken:存在于  baidu.com(baidu-int.com)域名下,cookie 的名字为  UUAP_P_TOKEN,线下环境统一为  UUAP_P_TOKEN_OFFLINE sToken:存在于下游系统的域名下面、该值为 uuap 认证成功后签发的 ticket 参数、下游系统获取后将其存入您的域名下,有效期 30 天、该值通用名称为  UUAP_S_TOKEN

  3. pToken 与 sToken

    • 如果 pToken 与 sToken 同时存在,则将 pToken、sToken 及您的 appKey 作为参数,发送 POST 请求到 UUAP-SESSION 的  Session 登录校验校验用户是否正常登录,如果正常登录返回登录用户的基本信息,未正常登录则返回状态码 204,重定向用户到  uuap 登录接口认证
    • 如果 pToken 与 sToken 不是同时存在,下游系统直接重定向用户到  uuap 登录接口认证。
  4. 如果 UUAP-SESSION 返回用户登录成功并且返回登录用户的基本信息,下游系统可允许用户访问受保护的内容。

  5. 如果 UUAP-SESSION 返回状态码 204,则按照 3-2 的步骤,下游系统直接通知前端跳转 UUAP-SSO 认证服务器认证。

  6. 下游系统携带 service 及 appKey 参数,访问 UUAP-SSO 的  uuap 登录接口接口请求用户认证。

    service:第 1 步中用户访问的下游系统的 url,请对该 url 进行 urlencode appKey:uuap 签发的下游系统唯一 id

  7. UUAP-SSO 认证服务器认证通过会在 baidu 的根域名下植入 pToken 的 cookie,并且会在用户传递的 service 回调地址后面追加 ticket 参数通知用户跳转,下游系统 server 可获取该参数,调用  SToken 置换接口获取 SToken,将其以 cookie 的形式存入你们的域名下,该值就是 sToken。

    • cookie 植入成功后要在之前访问 url 的基础上去除 ticket 参数让用户重新 302 访问一次,这样就能防止 server 看到访问 url 中存在 ticket 参数关键字陷入反复植入 sToken 的死循环,跳转后用户重新从第 1 步执行。
  8. 认证失败,跳转错误页面。


参考 #


本文访问量

本站总访问量

本站总访客数