单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
SSO是一种统一认证和授权机制,指访问同一服务器不同应用中的受保护资源的同一用户,只需要登录一次,即通过一个应用中的安全验证后,再访问其他应用中的受保护资源时,不再需要重新登录验证。
单点登录解决了什么问题
解决了用户只需要登录一次就可以访问所有相互信任的应用系统,而不用重复登录。
例如CSDN中的论坛应用,博客应用,下载应用模块。我们只要在CSDN中访问任何一个子应用后,再访问其他应用站点的时候就不需要在进行登录。
背景概述
实现方法
Server端
-
“共享Cookie”这个就是上面提到的共享session的方式,我倒觉得叫“共享session”来得好一点,本质上cookie只是存储session-id的介质,session-id也可以放在每一次请求的url里。据说这种方式不安全,我没去细究,哪位大神可以推荐下相关的资料,我后期补上。其实也是,毕竟session这项机制一开始就是一个server一个session的,把session拿出来让所有server共享确实有点奇怪。
-
SSO-Token方式因为共享session的方式不安全,所以我们不再以session-id作为身份的标识。我们另外生成一种标识,把它取名SSO-Token(或Ticket),这种标识是整个server群唯一的,并且所有server群都能验证这个token,同时能拿到token背后代表的用户的信息。我们要讨论的也是这种方式,一会上具体流程图。
浏览器端
-
单点登录还有非常关键的一步,这一步跟server端验证token的方式无关,用最早的“共享session”的方式还是现在的“token”方式,身份标识到了浏览器端都要面临这样的一个问题:用户登录成功拿到token(或者是session-id)后怎么让浏览器存储和分享到其它域名下?同域名很简单,把token存在cookie里,把cookie的路径设置成顶级域名下,这样所有子域都能读取cookie中的token。这就是共享cookie的方式(这才叫共享Cookie嘛,上面那个应该叫共享session)。比如:谷歌公司,google.com是他的顶级域名,邮箱服务的mail.google.com和地图服务的map.google.com都是它的子域。但是,跨域的时候怎么办?谷歌公司还有一个域名,youtube.com,提供视频服务。
技术实现机制
-
所有应用系统共享一个身份认证系统。
统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较,对用户进行登录认证;认证成功后,认证系统应该生成统一的认证标志(ticket),返还给用户。另外,认证系统还应该对ticket进行效验,判断其有效性。 -
所有应用系统能够识别和提取ticket信息
要实现SSO的功能,让用户只登录一次,就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取,通过与认证系统的通讯,能自动判断当前用户是否登录过,从而完成单点登录的功能。
单点登录在现在的系统架构中广泛存在,他将多个子系统的认证体系打通,实现了一个入口多处使用,而在架构单点登录时,也会遇到一些小问题,在不同的应用环境中可以采用不同的单点登录实现方案来满足需求。我将以我所遇到的应用环境以及在其中所经历的各个阶段与大家分享,若有不足,希望各位不吝赐教。
在网上看过不少的SSO实现方法。总结在实际项目开发中的一些开发体会。先看下面的流程图:
一、共享Session
共享Session可谓是实现单点登录最直接、最简单的方式。将用户认证信息保存于Session中,即以Session内存储的值为用户凭证,这在单个站点内使用是很正常也很容易实现的,而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题,在应用体系简单,子系统很少的情况下,可以考虑采用Session共享的方法来处理这个问题。
这个架构我使用了基于Redis的Session共享方案。将Session存储于Redis上,然后将整个系统的全局Cookie Domain设置于顶级域名上,这样SessionID就能在各个子系统间共享。
这个方案存在着严重的扩展性问题,首先,ASP.NET的Session存储必须为SessionStateItemCollection对象,而存储的结构是经过序列化后经过加密存储的。并且当用户访问应用时,他首先做的就是将存储容器里的所有内容全部取出,并且反序列化为SessionStateItemCollection对象。这就决定了他具有以下约束:
1、 Session中所涉及的类型必须是子系统中共同拥有的(即程序集、类型都需要一致),这导致Session的使用受到诸多限制;
2、 跨顶级域名的情况完全无法处理;
二、基于OpenId的单点登录
这种单点登录将用户的身份标识信息简化为OpenId存放于客户端,当用户登录某个子系统时,将OpenId传送到服务端,服务端根据OpenId构造用户验证信息,多用于C/S与B/S相结合的系统,流程如下
由上图可以看到,这套单点登录依赖于OpenId的传递,其验证的基础在于OpenId的存储以及发送。
1、当用户第一次登录时,将用户名密码发送给验证服务;
2、验证服务将用户标识OpenId返回到客户端;
3、客户端进行存储;
4、访问子系统时,将OpenId发送到子系统;
5、子系统将OpenId转发到验证服务;
6、验证服务将用户认证信息返回给子系统;
7、子系统构建用户验证信息后将授权后的内容返回给客户端。
这套单点登录验证机制的主要问题在于他基于C/S架构下将用户的OpenId存储于客户端,在子系统之间发送OpenId,而B/S模式下要做到这一点就显得较为困难。为了处理这个问题我们将引出下一种方式,这种方式将解决B/S模式下的OpenId的存储、传递问题。
三、基于Cookie的OpenId存储方案
我们知道,Cookie的作用在于充当一个信息载体在Server端和Browser端进行信息传递,而Cookie一般是以域名为分割的,例如a.xxx.com与b.xxx.com的Cookie是不能互相访问的,但是子域名是可以访问上级域名的Cookie的。即a.xxx.com和b.xxx.com是可以访问xxx.com下的Cookie的,于是就能将顶级域名的Cookie作为OpenId的载体。
验证步骤和上第二个方法非常相似:
1、 在提供验证服务的站点里登录;
2、 将OpenId写入顶级域名Cookie里;
3、 访问子系统(Cookie里带有OpenId)
4、 子系统取出OpenId通过并向验证服务发送OpenId
5、 返回用户认证信息
6、 返回授权后的内容
在以上两种方法中我们都可以看到通过OpenId解耦了Session共享方案中的类型等问题,并且构造用户验证信息将更灵活,子系统间的验证是相互独立的,但是在第三种方案里,我们基于所有子系统都是同一个顶级域名的假设,而在实际生产环境里有多个域名是很正常的事情,那么就不得不考虑跨域问题究竟如何解决。
四、B/S多域名环境下的单点登录处理
在多个顶级域名的情况下,我们将无法让各个子系统的OpenId共享。处理B/S环境下的跨域问题,我们首先就应该想到JSONP的方案。
验证步骤如下:
1、 用户通过登录子系统进行用户登录;
2、 用户登录子系统记录了用户的登录状态、OpenId等信息;
3、 用户使用业务子系统;
4、 若用户未登录业务子系统则将用户跳转至用户登录子系统;
5、 用户子系统通过JSONP接口将用户OpenId传给业务子系统;
6、 业务子系统通过OpenId调用验证服务;
7、 验证服务返回认证信息、业务子系统构造用户登录凭证;(此时用户客户端已经与子业务系统的验证信息已经一一对应)
8、 将用户登录结果返回用户登录子系统,若成功登录则将用户跳转回业务子系统;
9、 将授权后的内容返回客户端;
在实际的项目开发中会遇到各种情况,比如子站点和SSO主站点的接口调用参数约束,签名,加密等。以及纯html站点的实现SSO登录接口,或者纯.NET应用网站的跳转接口,这些都要区别开来。只有在详细了解SSO实现单点登录的原理之后进行开发才能做到事半功倍的效果。
五、安全问题
经过以上步骤,跨域情况下的单点登录问题已经可以得到解决。而在整个开发过程初期,我们采用用户表中纪录一个OpenId字段来保存用户OpenId,而这个机制下很明显存在一些安全性、扩展性问题。这个扩展性问题主要体现在一个方面:OpenId的安全性和用户体验的矛盾。
整个单点登录的机制决定了OpenId是会出现在客户端的,所以OpenId需要有过期机制,假如用户在一个终端登录的话可以选择在用户每次登录或者每次退出时刷新OpenId,而在多终端登录的情况下就会出现矛盾:当一个终端刷新了OpenId之后其他终端将无法正常授权。而最终,我采用了单用户多OpenId的解决方案。每次用户通过用户名/密码登录时,产生一个OpenId保存在Redis里,并且设定过期时间,这样多个终端登录就会有多个OpenId与之对应,不再会存在一个OpenId失效所有终端验证都失效的情况。
企业应用集成
现在企业开发流行Token验证也就是AK/SK的统一账号验证方法进行集中登陆验证,并且可以划分多个子账户进行权限管理。
【参考资料】
1、《浅谈架构之路:单点登录 SSO》 - https://www.cnblogs.com/shanrengo/p/6405262.html
2、偷懒小工具 - SSO单点登录通用类(可跨域) - Pino晨 https://www.cnblogs.com/chenxygx/p/5996391.html
3、单点登录(SSO)产品白皮书 – BBS . 云IDaaS平台 https://blog.idsmanager.com:843/bbs/?p=17
4、单点登录的三种实现方式 - CNode技术社区 https://cnodejs.org/topic/55f6e69904556da7553d20dd
5、SSO 单点登录 - CSDN博客 https://blog.csdn.net/ro_bot/article/details/53842062
6、CAS实现单点登录SSO执行原理探究 https://blog.csdn.net/javaloveiphone/article/details/52439613