单点登录是怎么回事

来源:互联网 发布:非诚勿扰网络播出时间 编辑:程序博客网 时间:2024/03/28 17:48
作者:程序猿讲故事 微信公众号

日期:2016年4月26日


单点登录的解决方案有很多,各个解决方案有自己的特点。本文不是为了介绍某一种单点登录方案,只是介绍单点登录的思路,以及必要的技术基础。

一、网站登录是怎么回事

在一个普通的网站开发中,Web Server怎么知道当前用户是谁?

1. 典型WEB

在典型的WEB应用中,应用大致包含三类数据:用户数据、权限数据、业务数据。用户打开浏览器后,首先跳转到登录界面,登录成功后就可以继续访问。下图是一个简单的描述。

问题来了,在登录成功后的后续访问中,服务器是怎么知道当前请求的用户到底是谁呢?我们都知道,HTTP是无连接的协议,每次浏览器的请求,对服务器来说都是一个新的请求,它怎么知道是上次登录的那个浏览器上发来的?

这就要提到两个概念:Cookie和Session。如果完全不懂这几个概念,自行找点编程书看看吧,还不太适合看这篇文章。

2. Cookie和Session的关系

在浏览器中,会维护一个Cookie,JavaWeb中这个Cookie名叫jsessionid。在Web Server中,会维护一个SessionMap,将一个jsessionid同一个Session对象进行绑定。这样,当浏览器访问时的jsessionid这个Cookie送到服务器后,服务器就能得到所对应的Session对象。

3. Cookie和Session的绑定过程

Cookie和Session的绑定过程如下

① 用户打开浏览器后第一次访问网站

用户第一次访问,服务器会创建一个新的Session对象和Cookie,实现二者的绑定,并将Cookie写入到用户浏览器中。

② 浏览器中后续访问时

用户后续访问时,浏览器会读出Cookie随同Request提交到服务器上,服务器根据Cookie,查找到当前浏览器对应的Session信息。

③ 用户登录成功时

用户登录成功后,服务器会在当前用户的Session中写入用户信息。

下次用户访问时,服务器根据Cookie得到用户的Session,就可以从中读出当前用户的信息。

4. WEB服务器集群部署会有什么问题

将WEB服务器部署为集群,如果不做任何设置,用户会话可能会出现丢失。

当用户在Server1中登录后,在Server1中创建了Session。如果下次用户被分发到Server2,这时候会无法得到Session信息,导致系统异常。

① 从前端分发处解决

让同一个浏览器发送来的请求,永远分发到同一台Server。

②Server的Session复制

③Server共享Session

多个Server,可以配置使用一个共享的Session信息,比如使用Redis保存会话。

二、单点登录需要解决哪些问题

整个应用环境,已经有很多套系统在运行,各自有自己的用户管理、登录管理。突然老板说要把所有的系统用户整合在一起,实现单点登录。怎么办?

1. 用户数据如何维护

原有的每个系统,都有自己的用户管理,整合单点登录后,怎么处理?大致会有以下一些处理方案:

① 各个系统中自行维护

这种方案最简单,用户管理部分不用做任何变化。但是需要做一些约定:相同的用户应该使用同一个登录名;用户在一个系统中进行了维护,必须在其他系统中同时维护。

②原有的一个主要系统中维护

原有的系统中,如果有一个侧重于用户信息管理的系统,可以将这个系统作为用户维护的主系统,其他系统不再保留用户管理功能,而改为从这个主系统中同步。

③独立一个用户管理系统

构建一套独立的用户管理系统,独立于原有的各个系统。如,使用LDAP、Windows Exchange。原有的用户系统都从这套系统中进行用户同步。

2. 用户数据同步的机制

前面采用了第二或第三种方案后,需要考虑用户数据如何同步的问题。可以考虑的有几种方案。为描述方便,将负责用户管理的系统称为主系统,其他系统成为子系统。

① 主系统主动推送

各系统实现同步信息变更接口。当用户信息变更后,主系统主动向所有子系统推送用户变更信息。这样,能保证用户信息得到实时的更新。

这种方案的缺点:1、更新时某个子系统正在存在故障,更新失败,以后可能找不到更新的时机了;2、某个子系统部署位置特殊,不能被主系统访问。

②子系统定期发起同步请求

主系统实现同步接口,由子系统定期主动发起同步请求。主系统将某个时间段之后的所有变更,按照特定格式封装后返回给子系统,由子系统负责解析并更新到本地用户表。

③用户登录后访问子系统时更新个人信息

用户登录后,跳转到子系统时,从主系统中查询当前用户的信息,并同子系统进行比较,如有变更则更新本地用户信息。

这种方案的缺点:1、如果用户不访问子系统,永远没有更新的机会;2、用户被删除或禁用,没有机会更新子系统。

三种方案各有特点,可根据情况选择,或者同时用多种方案配合实现。

3. 用户权限怎么实现

用户信息统一管理后,一个随之而来的问题,就是权限信息如何管理?简单分析,大致有三种解决方案:

① 各系统自行实现权限定义和判断

这个方案最简单,对原有系统不做任何修改。

这个方案有一个缺点:各个子系统的超级管理员如何设置。原来可能是将admin或root作为超管,可能各个子系统对超管账号设置不同,就会碰到定义困难。

②将权限统一管理

在用户管理主系统中,同时定义角色、权限等信息,在主系统中实现用户权限设置,并在用户跳转到子系统时,能够准确的读取到用户在本系统中的授权信息。

这个方案对更适用于新开发的系统,权限从头开发。针对老系统改造,可能修改工作量比较大。

③主系统定义部分权限

将前面两种方案整合,可以做一个新方案:由主系统定义子系统的部分权限,更多权限由各个子系统自行定义。

比如,主系统只需定义各个子系统的超级管理员。

4. 单点登录的一些备选方案

前面分析了用户和权限的改造,它们是为统一用户做基础准备工作。现在该讨论核心问题:如何实现单点登录?

列出一些能想到的解决方案。有些方案看似问题很大,但真有人这么做,因为:做起来简单。

① 域内Cookie共享

这是利用Cookie的特点,它是按照域名存储的。如果多个应用使用的是同一个域名,则这些应用都能读取到同一个Cookie。

如图,用户在主系统中登录后,创建一个cookie,域名设置为xyz.com。这时候,*.xyz.com的所有服务器,都能读取到这个域名。如果不指定域名,缺省使用的是主系统的域名www.xyz.com,其他子系统就不能读取同一个Cookie了。

子系统读取到userId这个cookie后,知道这是登录用户的id,从数据库中读取对应用户的信息并保存到Session中即可。

②传登陆用户的userId明文

用户在主系统中登录后,在主系统中提供子系统链接,并将用户说的唯一标识通过参数传递给子系统。

子系统读取到这个userId后,知道这是登录用户的id,从数据库中读取对应用户的信息并保存到Session中即可。

③传登陆用户的userId密文

如果觉得传输用户的userId明文不够安全,可以考虑将参数值加密进行传输。

子系统接收到userId参数的密文后,首先解密,知道这是登录用户的id,从数据库中读取对应用户的信息并保存到Session中即可。

④传递token替代userId

前面两种方案,通过链接传输用户ID,都不够安全。一旦黑客拿到了某个用户的userId或加密后的userId密文,他就能欺骗子系统。即使他并没有登录主系统,只需要传递同一个参数值,子系统就会认为该用户已经登陆。

因此可以设计出更安全的单点登录方案,用户访问子系统时,传递一个临时token,而不是真实的userId。

如果用户在主系统以用户admin登录,在主系统中生成一个token,保存在session中,并在所有的子系统链接中增加token参数。实际登录子系统过程变成如下:

1) 浏览器访问子系统1:web1.xyz.com?token=t12

2) 子系统拿到token=t12,不认识,它去问主系统:t12是谁?

3) 主系统拿到t12后,在自己维护的会话表中检查了一下,告诉子系统1:这是admin。

这样,用户就完成了登录子系统1的过程。

⑤ 使用一次性token

前面这个方案,整个会话周期,都是一个token,也不够安全。如果黑客拿到了访问第一个子系统的token,他就能在自己的浏览器中利用这个token访问第二个子系统,顺利完成登录。

这个方案针对方案4做改进,每次构造子系统链接时,生成一个新的token,当子系统验证用户成功后,立刻抛弃这个token,后续用户就不能再使用这个token进行验证。

这个方案还有两个明显的缺点

1) token的生命周期很长,黑客有可能抢在用户登陆子系统之前用token去验证,这样黑客反而抢在了真实用户的前面登录,真实用户进不去了。

2) 需要提前在主系统中为子系统创建链接并添加token参数,不够灵活。

⑥ 使用更成熟的单点登录解决方案

前三种方案都是比较简单的处理方法,不够安全。更安全合理的做法,是基于第三方成熟的解决方案进行定制,或者是参考这些方案,设计更符合环境特点的单点登录方案。

成熟的方案,大致有:CAS、OAuth1.0/2.0、OpenID,以及QQ等第三方提供的单点登录接入方案。

其中,CAS是一个非常成熟的解决方案,并且有Java、PHP等各种开发语言的子系统集成方案,网络上也有比较丰富的开发文档。当需要提供单点登录方案时,可以有优先考虑它,并进行必要的定制。

三、CAS的登录过程

网络上已经有丰富的CAS文档,我就不做拷贝粘贴的工作了。简单从网络上拷贝一段介绍CAS的登录过程,主要是为了同前述几个简单方案的区别。

【复制自:http://blog.csdn.net/nengyu/article/details/7086110】

CAS Client与受保护的客户端应用部署在一起,以Filter方式保护Web应用的受保护资源,过滤从客户端过来的每一个Web请求,同时,CAS Client会分析HTTP请求中是否包请求Service Ticket(上图中的Ticket),如果没有,则说明该用户是没有经过认证的,于是,CAS Client会重定向用户请求到CAS Server(Step 2)。Step 3是用户认证过程,如果用户提供了正确的Credentials,CAS Server会产生一个随机的Service Ticket,然后,缓存该Ticket,并且重定向用户到CAS Client(附带刚才产生的Service Ticket),Service Ticket是不可以伪造的,最后,Step 5和Step6是CAS Client和CAS Server之间完成了一个对用户的身份核实,用Ticket查到Username,因为Ticket是CAS Server产生的,因此,所以CAS Server的判断是毋庸置疑的。

该协议完成了一个很简单的任务,所有与CAS的交互均采用SSL协议,确保ST和TGC的安全性。协议工作过程会有2此重定向过程,但是CAS Client与CAS Server之间进行ticket验证的过程对于用户是透明的。


0 0
原创粉丝点击