单点登录系统的实现2

一、共享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模式下要做到这一点就显得较为困难。

三、基于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. 返回授权后的内容。

四、B/S多域名环境下的单点登录处理

      在多个顶级域名的情况下，我们将无法让各个子系统的OpenId共享。处理B/S环境下的跨域问题，我们首先就应该想到JSONP的方案。

                                      

验证步骤如下：

1. 用户通过登录子系统进行用户登录；
2. 用户登录子系统记录了用户的登录状态、OpenId等信息；
3. 用户使用业务子系统；
4. 若用户未登录业务子系统则将用户跳转至用户登录子系统；
5. 用户子系统通过JSONP接口将用户OpenId传给业务子系统；
6. 业务子系统通过OpenId调用验证服务；
7. 验证服务返回认证信息、业务子系统构造用户登录凭证；（此时用户客户端已经与子业务系统的验证信息已经一一对应）
8. 将用户登录结果返回用户登录子系统，若成功登录则将用户跳转回业务子系统；
9. 将授权后的内容返回客户端。

转自：dwz.cn/d90vKSJE