【功能实现】单点登录 / SSO - 学习/实践

宁小法

已于 2022-09-08 21:12:18 修改

阅读量4k

点赞数

分类专栏：功能场景-FUNCTIONAL SCENARIO 文章标签：单点登录 SSO

于 2020-01-10 21:51:57 首次发布

本文链接：https://blog.csdn.net/william_n/article/details/103931258

版权

功能场景-FUNCTIONAL SCENARIO 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1.应用场景

主要是学习，实践，实现单点登录，弄清楚其中的原理, 以及如何落到工作当中.

2.学习/操作

1. 文档

掘金 // 图文并茂，为你揭开“单点登录“的神秘面纱

https://baike.baidu.com/item/同源策略/3927875?fr=aladdin // 同源策略百度百科

浏览器的同源策略 - Web 安全 | MDN // 浏览器的同源策略 -- Web 安全 | MDN

企业透视 | Okta：密码管理“独行侠” - 知乎

2. 整理输出

2.1 介绍

单点登录( Single Sign On ，简称 SSO），是目前比较流行的企业业务整合的解决方案之一，用于多个应用系统间，用户只需要登录一次就可以访问所有相互信任的应用系统。

2.2 知识导读

想要弄清楚下面的实现原理，需要读下方文档，特别是第一个--浏览器的同源策略

浏览器的同源策略 - Web 安全 | MDN

CAS - CAS Protocol

2.3 实现方案

CAS

Yale设计的SSO协议，基于浏览器的SSO方案，部署简单，适用于简单的应用场景。

OIDC

在OAuth2的基础上额外加一个JWT来传递用户信息。功能全面强大，是目前很流行的SSO方案。

2.4 CAS

流程如下：

其中需要关注以下 2 点：

所有的登录过程都依赖于 CAS 服务，包含用户登录页面、ST 生成、验证；
为了保证 ST 的安全性，一般 ST 「Server Ticket」都是随机生成的，没有规律性。CAS 规定 ST 只能保留一定的时间，之后 CAS 服务会让它失效，而且，CAS 协议规定 ST 只能使用一次，无论 ST 验证是否成功，CAS 服务都会清除服务端缓存中的该 ST，从而规避同一个 ST 被使用两次或被窃取的风险。

其实前端什么都不用做, 都是后台在操作CAS。

举例, 普通网站 A.com B.com 统一登录网站S.com

未登录时候:

访问A.com, A站发现你没有登录, 就把网址重定向到S.com/?server=A.com, 此时浏览器在S站, S站发现没有登录,会让你输入账号密码, 然后确认, 好, 此时S站已经登录了, S站会生成1个session-对应的浏览器生成一个cookie(S站的), 下次访问S站, 是用这个cookie,
S站存完cookie后, 又会重定向到A.com/?ticket=asdsadad, 到此,又回到了A站, A站还是没有登录状态, 接下来A站后台发现你传了ticket参数, 后台会拿着 ticket 和A站的域名(A.com) 这两个东西去S站的后台去验证,这个是ticket是否有效,以及ticket这个人的身份信息, 如果正确, 则A站会生成一个session,给浏览器发放一个cookie(A站的), 此时A站完成登录状态, 浏览器会有2个不同的cookie (A站的, 和S站的).

B.com 免登效果:
然后用户访问B.com, B站(不是bilibili...) B站发现没有登录, 重定向到S.com/?server=B.com , 此时S站有cookie, S站发现用户已经登录, 不用输入密码了, 直接重定向到B.com/ticket=wqeipofvijwrpt, 接下和A站的流程一样了.... B站后台发现你传了ticket参数, 后台会拿着 ticket 和B站的域名(B.com) 这两个东西.....
用户只输入了B.com 会发现已经是登录状态
..写的有点乱, 也是自己的理解, 还请各大佬指正
例子中 A.com B.com 可能需要先向S站申请登录接口这样才能和S站对接,
比如B.com是你自己的网站 S站是腾讯或 github 这样你的网站就能用QQ登录或 github 账号登录了

补更：
之前说前端什么都不用做, 其实也不是：
1. 现在多是前后端分离项目，当我们请求接口的时候返回登录过期，还是需要前端调用CAS的方法跳转到登录端口（或手写跳到登录站加上callback），登录有方能跳转回来。
2. 有的CAS调回来之后并不是直接带ticket，而是带state和code，需要请求后端换取token（或session），然后前端需要存入cookie或Storage中，根据后端协商的鉴权方式，发请求的时候带上token即可。
3. 退出登录时，调用CAS的logout或清除cookie或并请求后台退出登录销毁token
-
附：一个CAS系统：Casdoor

Casdoor · A UI-first Identity Access Management (IAM) / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC, SAML and CAS | Casdoor · A UI-first Identity Access Management (IAM) / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC, SAML and CAS

注销和单点注销 (SLO)

CAS - Logout & Single Logout -- 可详细阅读

在 CAS 单点登录会话期间可能有许多活动的应用程序会话，注销和单点注销之间的区别基于注销操作时结束的会话数。

注销的范围取决于操作发生的位置：

应用程序注销 - 结束单个应用程序会话
CAS 注销 - 结束 CAS SSO 会话

请注意，在简单情况下，每种情况下的注销操作都不会影响其他情况。

结束应用程序会话不会结束 CAS 会话，并且结束 CAS 会话不会影响应用程序会话。

这是 SSO 系统的新用户和部署者混淆的常见原因。

CAS 中的单一注销支持试图协调 CAS 注销和应用程序注销之间的差异。

为 SLO 配置 CAS 时，它会尝试向在 SSO 会话期间向 CAS 请求身份验证的每个应用程序发送注销消息。虽然这是一个尽力而为的过程，但在许多情况下，它运行良好，并通过在登录和注销之间创建对称性来提供一致的用户体验。

SSO 会话与应用程序会话

为了更好地理解 CAS 的 SSO 会话管理以及它如何处理应用程序会话，首先要考虑一个重要的注意事项：

CAS 不是会话管理器
应用程序会话是应用程序的责任。

CAS 希望以安全 cookie 的形式在用户代理【浏览器】和 CAS 服务器之间共享的 TGT id 和 TGT id的形式维护和控制 SSO 会话。

CAS 不是应用程序会话管理器，因为应用程序负责维护和控制自己的应用程序会话。

身份验证完成后，就应用程序会话而言，CAS 通常不存在。

因此，应用会话本身的过期策略完全独立于CAS，在应用会话过期的情况下，可以根据理想的用户体验进行松散的协调和调整。

在未激活单点注销的情况下，通常，应用程序可能会公开一个注销端点以销毁会话，然后将代理【浏览器】重定向到CAS logout端点以完全销毁 SSO 会话。

2.5 OIDC

TBD

额外知识补充

IDaaS的全称是Identify as a Service，字面意思即身份即服务，是一种通过利用云基础设施，构架在云上的身份服务。

OKTA（美国）涵盖的平台服务： -- 之前的公司使用的服务，整合了很多应用，并不是自家的产品，比如Github，Jira，Slack，Wormly等

OKTA在北美市场，无疑已经成为IDaaS的领导者和标准。

Okta Identity Engine：提供定制的用户身份验证，授权和注册流程。

Okta目录：管理分层目录结构，以控制对文件、应用程序等资源的访问的逻辑。

Okta集成：提供框架，模板和工具，以将预先构建的应用发布到Okta集成网络。

Okta见解：汇总，分析和分发Okta数据以生成有用的见解，例如为安全策略提供个性化建议或为最终用户提供可疑的活动警报。

Okta工作流：允许自动化复杂的以身份为中心的业务流程。

Okta设备：收集设备特定的数据以管理身份资料和基于此的控制访问。