数仓沉思录(八)SSO的简单版

学习需要积极反馈才能做到有效监控,学习的过程是一个需要付出努力且不断试错的过程,善于调整学习动机,做好情绪管理,始终将关注点放在精通专业技能这一角度上,精益求精便指日可待。

题外话:终于买了一部新的thinkpad t480s本子,上一个t430跟了我5年多,终于可以退居二线,专用于影音娱乐码字用了!没有入坑MAC,总认为货不等值,再则Linux要比MacOS熟悉多了,不想再浪费时间,Linux上码代码同样非常爽。那些拿着Mac装着Windows的,这分明是赤裸裸地炫富嘛……

回正题:SSO英文全称(Single Sign On),中文单点登陆,优点自不必啰嗦,网上一堆相关描述,其中有几点很值得一提,一是提升用户体验,用户不用记忆那么多用户名和密码了,省心了很多;二是提升开发体验,一个大而复杂的系统可以拆成更小更细的子系统去完成,为落实系统模块化扫除障碍;三是如今采用REST架构的系统很多,系统部署在多个节点会遇到一个跨域的问题,有了SSO,可以很优雅的解决跨域的问题。

本文设计的SSO的功能包含有用户注册、修改密码、修改用户信息、信息查询等等常规用户管理模块应该有的功能,这些是次要的,主要看该怎么与其他系统交互!

设计图如下所示:

这里以用户访问受保护页面为例,交互流程描述如下:

1、用户通过浏览器访问子系统A

2、子系统A检查用户请求,是否有权限访问指定页面(这里举例为是否已登陆)

3、如果有,则返回指定页面,如果没有则向SSO服务器发起一个用户标识申请(UUID)

4、SSO服务器返回一个UUID给子系统A

5、子系统A协助SSO服务将UUID写入客户端COOKIE,并指定回调地址(指向SSO登陆地址)

6、用户浏览器访问指定的回调地址,执行登陆流程

7、SSO服务器将用户UUID与新产生的SESSION绑定,SESSION信息包含如超时时间,UUID等,SESSION信息保存在一个共享的缓存区中,通常是类似于Redis这样的集群中,所有子系统均可访问和更新,个人倾向于使用分布式KV且有用户概念,支持事务的系统中。

8、返回登陆结果信息

9、如果登陆成功,则继续访问指定的受保护页面

10、子系统A,根据用户提交的信息,这里主要是UUID,向SSO请求其他用户信息如角色、权限等

11、SSO服务器返回子系统A所需要的用户信息(每个系统所需的用户信息是不一样的)

12、子系统A返回指定页面,下面该干嘛就干嘛了

整个交互流程到此结束,当然后面还有超时退出和用户主动退出系统的操作,这个就不是关键问题了。该用户使用同一台设备登陆其他子系统,携带COOKIE中信息去访问就可以了,如果换了终端,当然必须得重新登陆了。

这样设计简单吧,而且SSO服务器的压力很小,数据与应用是分离的,SSO服务可以部N个实例都没有问题,所有子系统部署实例数也不会受限制,所有的压力都在分布式缓存上了。当然,这样的设计在公司内部受限的场景中使用是没有问题的,要用到公网上,还有安全问题是需要考虑的,比如缓存中的数据第一要防止被篡改,第二防止信息泄漏,像Redis这种处于安全性考量,是不能用于session缓存的,要用也要极其小心!

最后,要表示一下歉意的,每篇文章之后一般会提一下下一篇会写些什么,但因为工作内容会不断变化,导致有些承诺不能及时兑现,实在抱歉,所以从此篇开始不再提下篇的相关主题内容了

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180505G1GQ2S00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券