SSO模型及单点登录SSO技术选型

一、多系统的复杂性

web系统早已从久远的单系统发展成为如今由多系统组成的应用群，面对如此众多的系统，用户难道要一个一个登录、然后一个一个注销吗？就像下图描述的这样

web系统由单系统发展成多系统组成的应用群，复杂性应该由系统内部承担，而不是用户。无论web系统内部多么复杂，对用户而言，都是一个统一的整体，也就是说，用户访问web系统的整个应用群与访问单个系统一样，登录/注销只要一次就够了

虽然单系统的登录解决方案很完美，但对于多系统应用群已经不再适用了，为什么呢？单系统登录解决方案的核心是cookie，cookie携带会话id在浏览器与服务器之间维护会话状态。但cookie是有限制的，这个限制就是cookie的域（通常对应网站的域名），浏览器发送http请求时会自动携带与该域匹配的cookie，而不是所有cookie

既然这样，为什么不将web应用群中所有子系统的域名统一在一个顶级域名下，例如“*.”，然后将它们的cookie域设置为“”，这种做法理论上是可以的，甚至早期很多多系统登录就采用这种同域名共享cookie的方式。然而，可行并不代表好，共享cookie的方式存在众多局限。首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是web服务器）要相同，不然cookie的key值（tomcat为JSESSIONID）不同，无法维持会话，共享cookie的方式是无法实现跨语言技术平台登录的，比如java、php、.net系统之间；第三，cookie本身不安全。因此，我们需要一种全新的登录方式来实现多系统应用群的登录，这就是单点登录

二、什么是单点登录（SSO）

单点登录主要用于多系统集成，即在多个系统中，用户只需要到一个中央服务器登录一次即可访问这些系统中的任何一个，无须多次登录。单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

登录

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

下面对上图简要描述

用户访问系统1的受保护资源，系统1发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数

sso认证中心发现用户未登录，将用户引导至登录页面

用户输入用户名密码提交登录申请

sso认证中心校验用户信息，创建用户与sso认证中心之间的会话，称为全局会话，同时创建授权令牌

sso认证中心带着令牌跳转会最初的请求地址（系统1）

系统1拿到令牌，去sso认证中心校验令牌是否有效

认证中心校验令牌，返回有效，注册系统1

系统1使用该令牌创建与用户的会话，称为局部会话，返回受保护资源

用户访问系统2的受保护资源

系统2发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数

sso认证中心发现用户已登录，跳转回系统2的地址，并附上令牌

系统2拿到令牌，去sso认证中心校验令牌是否有效

sso认证中心校验令牌，返回有效，注册系统2

系统2使用该令牌创建与用户的局部会话，返回受保护资源

用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系

局部会话存在，全局会话一定存在

全局会话存在，局部会话不一定存在

全局会话销毁，局部会话必须销毁

你可以通过博客园、百度、csdn、淘宝等网站的登录过程加深对单点登录的理解，注意观察登录过程中的跳转url与参数

注销

单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明

sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作,下面对上图简要说明

用户向系统1发起注销请求

系统1根据用户与系统1建立的会话id拿到令牌，向sso认证中心发起注销请求

sso认证中心校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址

sso认证中心向所有注册系统发起注销请求

各注册系统接收sso认证中心的注销请求，销毁局部会话

sso认证中心引导用户至登录页面

三、SSO部署图

单点登录涉及sso认证中心与众子系统，子系统与sso认证中心需要通信以交换令牌、校验令牌及发起注销请求，因而子系统必须集成sso的客户端，sso认证中心则是sso服务端，整个单点登录过程实质是sso客户端与服务端通信的过程，用下图描述

sso认证中心与sso客户端通信方式有多种，这里以简单好用的httpClient为例，web service、rpc、restful api都可以

四、实现思路

sso采用客户端/服务端架构，我们先看sso-client与sso-server要实现的功能（下面：sso认证中心=sso-server）

sso-client

拦截子系统未登录用户请求，跳转至sso认证中心

接收并存储sso认证中心发送的令牌

与sso-server通信，校验令牌的有效性

建立局部会话

拦截用户注销请求，向sso认证中心发送注销请求

接收sso认证中心发出的注销请求，销毁局部会话

sso-server

验证用户的登录信息

创建全局会话

创建授权令牌

与sso-client通信发送令牌

校验sso-client令牌有效性

系统注册

接收sso-client注销请求，注销所有会话

五、SSO技术选型

cas（单点登录）

解决问题：多个系统只需登录一次，无需重复登录

原理：授权服务器，被授权客户端

授权服务器（一个）保存了全局的一份session，客户端（多个）各自保存自己的session

客户端登录时判断自己的session是否已登录，若未登录，则（告诉浏览器）重定向到授权服务器（参数带上自己的地址，用于回调）

授权服务器判断全局的session是否已登录，若未登录则定向到登录页面，提示用户登录，登录成功后，授权服务器重定向到客户端（参数带上ticket【一个凭证号】）

客户端收到ticket后，请求服务器获取用户信息

服务器同意客户端授权后，服务端保存用户信息至全局session，客户端将用户保存至本地session

默认不支持http请求，仅支持https

缺点：

cas单点登录技术适用于传统应用的场景比较多， 官方示例也是以javaWeb为准， 对微服务化应用，前后端分离应用，

支持性较差

oauth2（第三方登录授权）

解决问题：第三方系统访问主系统资源，用户无需将在主系统的账号告知第三方，只需通过主系统的授权，第三方就可使用主系统的资源（

如：APP1需使用微信支付，微信支付会提示用户是否授权，用户授权后，APP1就可使用微信支付功能了）

原理：主系统，授权系统（给主系统授权用的，也可以跟主系统是同一个系统），第三方系统

第三方系统需要使用主系统的资源，第三方重定向到授权系统根据不同的授权方式，授权系统提示用户授权用户授权后，授权系统返回一个授权凭证（accessToken）给第三方系统【accessToken是有有效期的】第三方使用accessToken访问主系统资源【accessToken失效后，第三方需重新请求授权系统，以获取新的accessToken】

OAUTH2中的角色：

Resource Server: 被授权访问的资源Authotization Server：OAUTH2认证授权中心Resource owner : 资源拥有者Client：使用API的客户端(如Android 、IOS、web app)

工作流程如下：

jwt (客户端token)

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

基于JWT认证协议，自己开发SSO服务和权限控制。 流程如下

六、安全控制框架

spring-security

spring-security 是spring家族的安全控制框架， 功能非常完善。 Spring Security是能够为J2EE项目提供综合性的安全访问控制解决方案的安全框架。它依赖于Servlet过滤器。这些过滤器拦截进入请求，并且在应用程序处理该请求之前进行某些安全处理。

Spring Security对用户请求的拦截过程如下:

shiro

Apache Shiro 是一个强大而灵活的开源安全框架，它干净利落地处理身份认证，授权，企业会话管理和加密。

以下是你可以用 Apache Shiro 所做的事情：

1.验证用户来核实他们的身份2.对用户执行访问控制，

2.1判断用户是否被分配了一个确定的安全角色

2.2判断用户是否被允许做某事3.在任何环境下使用 Session API，即使没有 Web 或 EJB 容器。4.在身份验证，访问控制期间或在会话的生命周期，对事件作出反应。5.聚集一个或多个用户安全数据的数据源，并作为一个单一的复合用户“视图”。6.启用单点登录（SSO）功能。 内置了jasig-cas7.为没有关联到登录的用户启用"Remember Me"服务

主流的技术搭配 spring-security + oauth2spring-security + cas 功能较弱，对前后端分离的项目支持不是很好shiro + cas比较

七、SSO落地实现技术

/p/94622931

参考文章

参考文章