SSO单点登录的发展由来以及实现原理

  1. 云栖社区>
  2. 博客>
  3. 正文

SSO单点登录的发展由来以及实现原理

风间影月 2017-02-20 17:23:00 浏览718
展开阅读全文

单点登录以及权限,在很早之前都有写过,不过都比较简单,今天就具体说一下,以及下一步要做的

1、web单系统应用

早期我们开发web应用都是所有的包放在一起打成一个war包放入tomcat容器来运行的,所有的功能,所有的业务,后台管理,门户界面,都是由这一个war来支持的,这样的单应用,也称之为巨石应用,因为十分不好扩展和拆分。

在巨石应用下,用户的登录以及权限就显得十分简单,用户登录成功后,把相关信息放入会话中,HTTP维护这个会话,再每次用户请求服务器的时候来验证这个会话即可,大致可以用下图来表示:

 如上图,这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览器中看到JSESSIONID,这个就是用来维持这个关系的key

这样,每次请求的时候只需要用拦截器来拦截当前用户的登录状态以及授权状态即可。

如果引入集群的概念,这个单应用可以分别部署在3台tomcat上,使用nginx来实现反向代理, 此时,这个session就无法在这3台tomcat上共享,用户信息会丢失(这里不考虑粘性和非粘性的session,我们不推荐做)

2、多应用构建的分布式集群系统

从巨石应用发展至今,我们有SOA,有微服务,其道理都是一样的,都是进行了业务拆分来分解为多个系统,多个系统完全解耦,可以分别部署在不同的服务器上,项目之间通过rpc或者restful来实现相互通信,举个栗子:

order.abc.com

cart.abc.com

service.abc.com

有这么3个系统,部署在不同的二级域名下,那么用户每次登陆不同的系统是不是都要登录呢?这样是不合理的,我们不能因为系统的复杂度使得用户也变得复杂,对于用户来说,一套产品就是一个完整的应用。登录一次即可,没有必要多次登录。

按照之前所说的session就不适用了,在这个地方我们就引入了单点登录,保持用户与服务端之间的无状态协议,生成token,使用token这个令牌穿梭在各个系统。

那么这个token放在浏览器cookie即可,失效时间需要和redis的expire一致,根据需求我们可以实现用户登录一次就可以在任何系统中使用,其次用户账户在别的地方登录后,上一个用户则被挤出。

(需要注意的是,这个cookie作为第一方cookie需要对二级域名进行设置,如果要跨域的话需要设置第三方cookie或者使用JWT来做,这个就不多说了)

 

3、单点登录SSO(Single Sign On)

对于分布式系统来说,我们需要sso这样一个用于单点登录的系统,可以独立部署在一个web服务器内,比如域名为 login.abc.com,其他所有web服务上的登录都可以通过这个sso来登录,app也可以调用登录

如果,所有的token都由sso来管理,这个token在浏览器可以存储在第一方cookie或者第三方都行,在ios或者安卓上也能够保持,每次访问服务的时候放入headers中,让拦截器进行验证即可。同时,这个token也可以扩展用来做权限。

 

4、手机端的单点登录

这个不难理解,就像微信那样,同一个用户只能在同一个手机端上登录,这个是用token+缓存就能实现,套用上面所说的拦截器,可以不需要写很多代码就能实现。

 

5、代码实现以及部署

关于这个我会在这段时间抽空写个简单小项目放在github上开源。

 

网友评论

登录后评论
0/500
评论
风间影月
+ 关注