《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 urlify.cn/bQBjyu 「nodotnet」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

Single Sign-on

SSO是老生常谈的话题了,但部分同学对SSO可能掌握的也是云里雾里,一知半解。本次手撕公司的SSO原理,试图以一种简单,流畅的形式为你提供有用的SSO原理。

按照本人一贯行文风格,我们先说什么是SSO,为什么要提出SSO?

SSO:在多个系统中,只需要登陆一次,就可以访问其他相互信任的应用系统, 这个技术的提出解决了:

1.企业运行了多个服务,而账号需要集中统一管理

2.终端用户登陆一次,即可使用一个账户享受所有不同域名下服务。

SSO 与CAS(Central Authentication System)这个概念密切相关,账户集中由某个服务管理,SSO服务只负责登陆认证。

登陆认证与【服务端在浏览器上写入的认证Cookie】密切相关, Cookie 有一系列重要属性:Domain,Path, Expiration,HttpOnly 决定了该Cookie 在客户端的作用域、作用范围、有效时间、有效操作方式

原理

用户首次访问 website1

① 用户访问website1 系统,website1系统需要认证, 用户当前没有登陆

② website1给客户端返回302重定向响应, 客户端重定向到SSO服务页

交互过程确实是临时跳转,下面传参false, 返回302临时重定向响应

context.Response.Redirect(ssoURL, false);

用户并没有登陆SSO系统,所以SSO系统会返回登陆界面

③ 用户在SSO登陆界面输出账户/密码

④ 登陆成功,SSO会在客户端写入一个 cookie for sso并产生一个301重定向响应,客户端将重定向到原website1地址,该请求附带了SSO给与这次认证成功的 ticket

http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO

⑤ website1收到以上重定向请求,解析QueryString中的ticket, 向SSO做一次ticket验证;验证通过向客户端写入本站的 cookie for website

⑥ 上面第5步,浏览器地址会显示:http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO, 在本站验证通过之后,最好再做一个重定向,返回业务首页:www.website1.com, 本步骤不是SSO登陆的标准流程。

之后用户访问website2

① 用户访问website2, 用户在website2并没得到认证;跳转回 SSO

② SSO服务检测到该 用户在SSO域下存在Cookie for sso, 认定该用户已经登陆,故跳转回website2, 如上也会携带认证ticket

③ 如上,website2收到 website2.com?ticket=XXXX-OOOO-XXXX-OOOO请求, 会做一次SSO验证;验证成功,写入本站cookie for website2

重难点解读

① SSO认证成功,写入的cookie for sso, 是登陆到其他系统的关键

② website1收到SSO发起的重定向请求,解析出ticket=XXXX-OOOO-XXXX-OOOO, 为什么还要做一次SSO验证?

因为website1收到的带ticket请求,有可能是伪造, 所以在website1中需要去SSO验证一次。

③ 标准的CAS登陆流程有两次302客户端重定向, 分别由原站点website1和SSO启动。

理论上 整个流程由服务端重定向也是可以的 ??看官若发现有漏洞,可在评论区回复。

④ 退出SSO登陆, 要做两件事情:

  • 向SSO发起api请求,请求SSO删除用户在SSO域下的认证cookie for sso

  • 移除本站的cookie for website1

⑤ 每个website,至少需要如下sso配置

"SsoOptions": {
"BaseAddress": "https://sso-cas.sso.com",     // 基地址
"LoginPath": "/login", // sso登陆地址
"LogoutPath": "/api/logout", // 退出sso登陆的api地址
"ValidateTGTPath": "/api/validate", // 验证ticket的api地址
"UserInfoPath": "/api/v2/userinfo" // 从sso拿到登陆用户信息的api地址
},

That' all,这是自己对SSO登陆的一些理解, 本图文希望以流畅的思路记录SSO流程, 各位看官不要吃快餐,知其然更知其所以然很关键。

文章目录
  1. 1. Single Sign-on
  2. 2. 原理
  3. 3. 用户首次访问 website1
  4. 4. 之后用户访问website2
  5. 5. 重难点解读