单点登录系统SSO——理论
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了单点登录系统SSO——理论相关的知识,希望对你有一定的参考价值。
关于SSO一直没有深入的研究,在工作中也是对接的公司平台的SSO,最近频繁的与SSO打交道之后,我决定深入的理解一下它的实现原理;
一.SSO的实现种类
SSO系统在公司一般是独立部署的一套系统,需要各业务系统接入,回想一下之前传统系统都是业务+登录一体化,那个时候,我们可以将用户信息保存到session,那如果是微服务+独立SSO该怎么实现各系统session共享的问题?
1.基于共享session
我们都知道每台服务的session是互相不共享的,假设将我们的 商品服务、订单服务等服务的session都共享,就可以实现一处登录,全站访问的特点;
实现共享session的方式不是本文的重点,它存在一定的缺陷,就是所有的服务器都必须保持一致,不能说有些服务是tomcat,有些是jetty;
提升一种思路就是通过 Spring Session 或者 tomcat-redis-session-manager
2.基于认证中心
这种方案需要自己实现一套SSO或使用第三方的,所有系统的认证操作都是在这个系统中完成的,它管理着整个用户的状态,这种实现方式需要SSO系统提供有登录、注册等操作的前端页面。下面重点介绍下实现方式;
二.实现方式
我们模拟三个服务:
系统A:a.demo.com
系统B:b.demo.com
SSO:sso.demo.com
1.登录流程
关键点:
1.它用到了两个cookie(sid与token)和三次重定向;
2.token是写到a.demo.com域名下的,sid是写到sso.demo.com域名下的;
3.在验证token的时候,如何知道当前用户已经创建了全局会话?因为jwt的payload里面存储了之前创建sso的会话sid,所以当cas拿到jwt,就相当于知道了sid;
注意:
SSO服务如果是集群部署的,则需要解决sid共享问题;
2.访问系统B的页面
在这个过程中关键在于第一次重定向的时候,它会把sso.demo.com这个域名下的sid带给sso服务;
3.退出
最重要的是要清除sid的cookie,jwt的cookie可能业务系统都有创建,所以不可能在退出的时候还挨个去清除,只要sid一清除,那么即使那些jwt的cookie在下次访问的时候还会被传递到业务系统有服务端;
三.总结
在真实的项目中,可能需要考虑到更多的安全性的要求,比如:
1.使用https
2.http-only
3.CSRF
总的来说,优缺点主要有:
1.能够支持跨平台,跨语言实现单点登录;
2.重写向次数过多;
3.每次请求都需要调用SSO验证token有效性;
以上是关于单点登录系统SSO——理论的主要内容,如果未能解决你的问题,请参考以下文章