最强SSO单点登陆教程(二)单点登陆流程分析

1、简介

单点登陆（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只须要登陆一次就能够访问全部相互信任的应用系统。

2、应用场景

如公司有多个系统，分别OA系统、CRM系统、财务管理系统、设备管理系统等，总不能访问每一个系统都要登陆一遍吧，用户会疯掉的，应该咱们认证一遍，其余系统便可访问。网上不少项目都在使用SSO单点登陆,好比天猫,淘宝,CSDN,博客园.

3、流程分析

相比于单系统登陆，sso须要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其余系统不提供登陆入口，只接受认证中心的间接受权。间接受权经过令牌实现，sso认证中心验证用户的用户名密码没问题，建立受权令牌，在接下来的跳转过程当中，受权令牌做为参数发送给各个子系统，子系统拿到令牌，即获得了受权，能够借此建立局部会话，局部会话登陆方式与单系统的登陆方式相同。这个过程，也就是单点登陆的原理，用下图说明:

单点登陆原理

步骤分析:
1.用户经过浏览器访问WMS(进销存)系统的受保护资源,访问地址为:http://www.wms.com/index,该资源为受保护资源,因此须要先判断一下用户登录了.(是否有局部会话)
2.WMS系统发现用户并无登录,此时重定向到统一认证中心,并把请求地址做为参数传过去.
3.此时浏览器发出一个请求查看统一认证中心是否已经登陆了?发现用户并无登陆,转发到统一认证中心的登录页面.
4.用户输入帐号密码.
5.统一认证中心认证用户信息.若是认证成功,建立浏览器与统一认证中心之间的会话，称为全局会话.同时建立受权令牌.重定向到WMS以前请求的地址,并把令牌信息带上.http://www.wms.com/index?token=4KLdkEo9k7CXfle4
6.WMS拿到令牌后,须要到统一认证中心检验令牌是否有效.
7.统一认证中心认证令牌有效,返回有效,并注册WMS的系统地址.
8.WMS获得统一认证中心的响应,知道令牌是有效的,建立局部的会话.并放行请求
9.WMS后续的请求访问的时候,发现WMS系统中有局部的会话,直接就放行了.
10.用户访问CRM(客户关系管理)系统的受保护资源,访问地址为:http://www.crm.com/index
11.WMS系统发现用户并无登录(没有局部会话),此时重定向到统一认证中心,并把请求地址做为参数传过去.
12.此时浏览器发出一个请求查看统一认证中心是否已经登陆了?发现用户已经登陆了,从会话中取出令牌,重定向到CRM系统,并把令牌带上.http://www.crm.com/index?token=SrEpDwAQlHLdkJIE
13.CRM拿到令牌后,须要到统一认证中心检验令牌是否有效.
14.统一认证中心认证令牌有效,返回有效,并注册CRM的系统地址.
15.CRM获得统一认证中心的响应,知道令牌是有效的,建立局部的会话.并放行请求
16.WMS后续的请求访问的时候,发现WMS系统中有局部的会话,直接就放行了.

用户登陆成功以后，浏览器会与统一认证中心及各个子系统创建会话，浏览器与统一认证中心创建的会话称为全局会话，浏览器与各个子系统创建的会话称为局部会话，局部会话创建以后，浏览器访问子系统受保护资源将再也不经过统一认证中心，全局会话与局部会话有以下约束关系.

1.局部会话存在，全局会话必定存在
2.全局会话存在，局部会话不必定存在
3.全局会话销毁，局部会话必须销毁

同窗们花20分钟时间把这张流程图好好理解理解.

4、系统中的Cookie和Session存储图解

这个执行流程里面很关键的点是统一认证中心和各个子系统的cookie和session是如何存储的?若是把里面的cookie和session搞清楚了,单点登陆原理基本已经理解90%了.
下面咱们就经过图解的方式来看看,上面的访问流程中每一个系统中的cookie和session是怎么存储的.

注意:如下图解是方便同窗们理解所画的,可能有细节和真实状况有细微出入.可是不影响理解,但愿不要钻牛角尖,能看懂便可.

图01:下图中,咱们有三个服务器,分别是统一认证中心:www.sso.com,CRM客户关系管理系统:www.crm.com,WMS经销存系统:www.wms.com.每一个系统都有一个区域存储session的地方,同窗们能够暂时理解就是有个map来存储session对象.这个map的key存的是session的id,value存的是session对象.
在浏览器本地会有三个目录存储对应域名的cookie.好比:访问www.crm.com的时候会在浏览器本地的crm.com目录找对应的cookie,并在请求的时候把这个目录下的cookie请求一并的带到服务器.(这个动做是浏览器完成的,不须要用户操做.),并且www.crm.com服务器响应cookie的时候会写入到浏览器本地的crm.com目录.
目前咱们还没发起请求,因此全部的内容都是空的.

单点登陆01

图02:第一次访问http://www.crm.com/employee,首先会在浏览器本地的crm.com目录中寻找是否有对应的cookie,若是能够没有说明目前浏览器和服务器之间尚未创建会话,也就是说没有局部的会话.
这时候咱们须要重定向到统一认证中心,查看是否有全局会话(若是有全局会话说明有其余系统已经登陆了).
须要把请求访问的地址做为参数传递过去,由于待会得回调这个地址.
具体代码以下:

String url = "http://www.sso.com/checkLogin?redirectUrl=http://www.crm.com/employee";
response.sendRedirect(url);

单点登陆02

图03:由于重定向,浏览器会调用统一认证www.sso.com中的checkLogin方法,查看是否有全局的会话.
这时候是请求http://www.sso.com/checkLogin地址,浏览器会在本地的sso.com目录找对应的cookie信息并在请求的时候一并得带到服务器.
可是此次的请求,浏览器本地目录sso.com中并无cookie信息,意味浏览器和统一认证中心之间尚未创建会话.
没有会话说明并无登陆.此时要转发到统一认证中心的登录页面.
须要把地址栏中的redirectUrl从地址栏中获取出来.

request.getParamter("redirectUrl");

并把这个参数放入到request域中.由于在登录成功以后要跳转到用户以前访问的地址.

单点登陆03

图04:转发到统一认证中的登录页面.

单点登陆04

图05:用户在统一认证中心的登录页面输入了帐户名和密码以后.统一认证中心服务器对用户信息进行认证.认证经过须要作这几个事情:
1.建立令牌,后续操做中得发给子系统,至关于间接受权.
2.建立全局会话,并把令牌存储到全局会话中.
3.把令牌信息存储到数据库中的t_token表中.主要是后续客户端校验token的有效性须要查询这种表.
4.重定向到以前用户请求的地址redirectUrl.并把令牌发给该子系统.http://www.crm.com/employee?token=VcnVMguCDWJX5zHa

统一认证中心会把session的id(咱们也称为JSESSIONID)响应到客户端浏览器本地目录sso.com的cookie文件中.存储的结构是key/value格式.key是固定的字符串JSESSIONID,value是服务器sessionid的字符串.
在后续访问www.sso.com的时候都会带上这个JSESSIONID

单点登陆05

图06:由于重定向,浏览器访问http://www.crm.com/employee?token=VcnVMguCDWJX5zHa,此时浏览器会在本地的crm.com把全部的cookie一并的带上.
可是本地的crm.com目录中没有内容,说明浏览器尚未和CRM系统创建会话,说明没有局部会话.
可是此次的请求中包含了token令牌的信息.
可是token是直接拼接在地址栏上的,存在被伪造的可能性.因此咱们须要对token令牌作有效性的校验.

单点登陆06

图07:CRM系统在接受到令牌token信息以后,须要去统一认证中心中校验令牌信息是否有效.
咱们使用HttpUrlConnection发送http请求http://www.sso.com/verify?token=VcnVMguCDWJX5zHa
统一认证中心接受到这个请求后,拿到令牌token对应的值,在数据库表t_token中查询是否有这条记录.若是能找到说明这个令牌是统一认证中心发放的,返回true给调用者.
若是找不到,说明不是统一认证中心产生的,咱们就该返回false给调用者.

单点登陆07

图08:CRM系统发送的校验请求以后,统一认证中心返回true的结果.说明令牌是有效的.此时须要作这几件事情:
1.建立局部的会话,而且标记这个会话已登陆,设置isLogin=true
2.放行该次的请求.
服务器会把session的id响应到客户端,存储在浏览器本地目录crm.com目录的cookie文件中.在后续访问www.crm.com的域名的时候会把该目录下的cookie信息一并带上.

到这一步其实咱们单个系统的登录就已经完成了.

单点登陆08

图09:后续的请求.好比请求http://www.crm.com/department,首先根据请求的域名在本地crm.com目录中找到对应的cookie信息,在请求的时候会把这个JSESSIONID一并的带上,经过这个JSESSIONID能够找到服务中属于该浏览器的会话对象,并查看isLogin属性,若是为true,就直接放行该次的请求.

单点登陆09

图10:此时咱们访问http://www.wms.com/orderBill地址,浏览器根据域名会在本地的wms.com目录中把cookie信息在请求的时候一并带上,可是并无cookie信息,说明浏览器尚未和WMS系统创建会话.
WMS没有局部会话,咱们就要重定向到统一认证中心的checkLogin方法,查看是否有全局的会话(是否有其余的系统登录了).

单点登陆10

图11:由于重定向的关系,浏览器发送请求:
http://www.sso.com/checkLogin?redirectUrl=http://www.wms.com/orderBill,
校验是否有全局的会话,由于以前CRM已经登陆了,因此有全局会话.
须要作如事情:
1.从全局会话中取出令牌信息token
2.重定向到子系统以前访问的地址,并把令牌信息带上.
http://www.wms.com/orderBill?token=VcnVMguCDWJX5zHa

单点登陆11

图12:由于重定向,浏览器发送请求:
http://www.wms.com/orderBill?token=VcnVMguCDWJX5zHa,
浏览器会根据域名找本地目录中wms.com目录中的cookie,并在请求的时候一并的带上.
可是并无cookie信息,说明没有局部会话,可是有令牌信息token.
须要到统一认证中心校验令牌信息token的有效性.

单点登陆12

图13:WMS系统后台经过HttpUrlConnection的方式发送请求,校验token是否有效.
统一认证中心接受到请求以后,拿到token在数据库表中查看是否有这条记录.并响应对应的结果信息到WMS系统中.

单点登陆13

图14:若是认证中心的返回的校验结果为true,说明令牌有效.那就在WMS中建立局部的会话,并在会话中设置登录属性isLogin=true.
放行请求
浏览器会默认的被sessionid的信息经过cookie的方式响应到浏览器.
浏览器把sessionid信息存储到wms.com目录的cookie文件中.

单点登陆14

图15:后去访问WMS其余的受保护资源.好比:http://www.wms.com/customer,浏览器会在本地wms.com目录中找cookie,并在请求的时候一并的把cookie信息带到服务器.
经过JSESSIONID找到数据该浏览器的会话对象,检查isLogin属性是否为true.
放行请求.

单点登陆15

当这步结束以后,在CRM系统和WMS系统中都存在局部的会话,咱们访问这两个系统中的任何受保护资源都会直接放行.

5、总结

同窗们须要花点时间好好把上面的流程和cookie和session存储图解弄清楚了.代码实现就变得So Easy.并且开源的单点登陆框架内部的实现和分析的流程基本上一致.

做者：叩丁狼教育
连接：https://www.jianshu.com/p/5cc... 来源：简书 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。