1.定义

        英文名Single Sign On，简称SSO，简单理解为：在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

包含两部分：

（1）单点登录

（2）单点注销

2.单系统登录以及多系统登录

（1）单系统登录

        a.依赖机制（会话，原因是http协议是无状态协议，并且会话可以使得浏览器和服务器维持一个状态）

        现在web应用采用browser/server架构（B/S，浏览器/服务器），选用http作为通信协议。并且http是无状态协议，对于浏览器的每一次请求，服务器都会单独处理，不与前后的请求产生任何关联，如下图1可明确关系：

图1 http请求关系图

        通过上图可以明确，每次请求是互不相关联的，并且每个浏览器或者说每个用户都是可以访问服务器获取信息的，那么这时就会想到如何去保护服务器资源，只允许某些符合要求的请求去访问服务器资源，就需要限制浏览器请求，由于http协议是无状态的协议，无法通过该http请求来限制，所以那么就需要在服务器和浏览器之前创建一个状态，去共同维护这个状态，这个就是会话机制。

        会话实现了每个后续请求与第一次请求的关联，当用户通过浏览器第一次请求服务器，服务器就会创建一个会话，并且服务器响应浏览器时，会将会话的id作为响应的一部分发送给浏览器，浏览器会暂时存储这个会话id，并且在后续的请求中都会带上这个会话id，服务器再通过该会话id就可以去判定当前请求用户与之前用户是否相同了，如下图2可清楚了解到会话在浏览器和服务器之前的关联：

图2 会话在浏览器和服务器之间的关系

        b.会话在服务器和浏览器中的保存形式

        服务器在内存中保存会话对象（session）。

        浏览器则是采用两种方式保存会话id，如下：

        （a）url请求参数存储

        这种方式是在每一个请求的url的请求参数中添加上会话id，那么当浏览器发出请求后，服务器获取到请求后就可以拿到会话id，并通过它来判断是否同一个会话（用户）。但，通过这种方式来判断是否为同一会话（用户）比较麻烦。

        （b）cookie存储

        cookie是浏览器用来存储少量数据的一种机制，并且以“key/value”的数据格式存储，使用浏览器的cookie机制可以很好的来维护会话id，cookie会在每一次http请求是自动被http请求附带，那么服务器每一次接收请求时都可以获取到http请求所附带的cookie信息，从而判断请求的会话是否为与之前相同的会话。    

        对于服务器tomcat，tomcat的会话机制也实现了cookie，所以当tomcat中设置了会话之后，tomcat响应浏览器之后，浏览器就会设置一个名为“JSESSIONID”的cookie，这个就相当于tomcat会话机制中的会话id，tomcat创建了会话响应以及浏览器带cookie请求的流程图如下图3：

图3 存在cookie的请求与tomcat响应过程图

        通过上图可以确认，浏览器第一次请求之后，tomcat服务器会创建会话，并响应给浏览器，这时，浏览器会设置名为“JSESSIONID”的cookie，浏览器在后续的所有请求中，都会带上这个cookie去请求tomcat服务器，从而tomcat服务器可以确认前后会话的一致性，从而达到我们想要的限制浏览器部分请求的目的。

        c.通过会话确认用户在服务器的登录状态

        登录流程如下：

        （a）第一次请求，用户在浏览器输入账户和密码，浏览器将这些信息传输给tomcat服务器

        （b）tomcat服务器创建会话

        （c）验证用户名和密码是否正确（正确）

        （d）设置登录状态isLogin()为true（并将登录标识存入会话）

        （e）第一次响应（带上tomcat的会话id：JSESSIONID）

        （f）浏览器设置名为JSESSIONID的cookie

        （g）第二次请求，带上名为JSESSIONID的cookie请求服务器

        （h）在服务器端查看登录状态isLogin()

        （i）第二次响应（此时响应不带会话id）

        ......

        单系统登录流程图如下图4所示：

图4 单系统登录流程图

        （2）多系统登录

        上面以及介绍单系统是如何登录的，但是如果多系统都使用单系统的登录方式，就会发现，多系统中的每个系统都需要登录一次，这样不仅繁琐，用户操作起来实用性也是很低，这样就达不到我们想要得到的效果：登录一次无需再次登录。如图5，用户登录多系统。

图5 用户登录多系统复杂图

        这里相当于提高了用户的操作负担，那么我们就应该思考了，如何使得用户只需要登录一次就可以进入所有系统，也就是说相当于把多系统看成一个系统（系统群），在任意一个子系统登录都可以进入其余的任意系统（注销同理），也就是达到如下图6所示的效果。

图6 用户登录多系统期望图

        上面提到cookie可以解决单系统登录，cookie会携带会话的id在浏览器和服务器之间维护会话状态，那么为什么cookie不能解决多系统的登录呢，原因其实就是cookie的域（常指每个系统网站的对应域名），对于浏览器在发送http请求时，它会自动携带与该域匹配的cookie，但不是所有cookie，这样每个域下面的cookie不同，那么就无法维护系统与系统之间的会话状态，如下图7。

图7 跨域cookie关系图

        这时就发现，跨域后cookie无法处理多系统之间（一个应用群）的登录问题，那么将所有系统分配在同一个域名下面，再使用cookie就可以维护它们之间的会话状态，就能达到我们的预期目标了，但其实这种同域方式虽可以解决上面说的多系统登录问题，但是它存在比较多的局限性，实现之后的效果其实并不是最理想的，主要有以下几个原因（缺点）：

        a.所有系统的域名必须统一，增加这之间的处理时间以及配置过程

        b.应用群中的各个系统使用的技术（至少是web服务器，比如Java、.net、php等）必须相同，否则cookie的key值（tomcat为JSESSIONID）就不相同，无法在各个系统之间维护会话状态，因为共享cookie的方式是无法实现跨语言技术平台登录的，这极大的限制了开发的多样性，以及极大的限制了开发各个系统的开发人员必须都使用相同语言，一旦某个系统使用一种语言，其他系统必须使用相同语言，不懂此门语言的开发人员将无法介入其中，增加成本。

        c.cookie本身不安全，因为cookie存在浏览器（客户端），一些别有用心的人拿到cookie（就算加密）之后，不需要知道指定的cookie的具体含义，只需要拿到这个cookie向服务器提交，就能够冒充受害人身份登录网站（cookie欺骗），这样会对个人信息造成严重危害（可深入了解cookie安全性问题）。

        上面说了那么多，那么哪种方式才是实现多系统之间的登录的更优方式，其实就是单点登录。

3.单点登录的原理

        文章开头已经说明，单点登录是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

        那么如何才能只登录一次就可以访问所有系统呢？有一个指定的唯一的统一处理验证用户信息的身份认证中心是关键。

        具体介绍以及单点登录流程如下。

        （1）单点登录

        相比较于单系统登录而言，要想实现单点登录，就需要一个独立的身份认证中心，只有认证中心能够接受用户名和密码等安全信息，统一处理验证用户信息，是否登录成功由验证中心发出，其他系统不提供登录入口，只接受认证中心的间接授权。

        间接授权主要通过该令牌实现，认证中心拿到用户名和密码之后，会验证用户名和密码是否正确，确认用户名和密码正确之后，认证中心创建授权令牌，在之后的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到了令牌，那么就相当于得到了授权，对应子系统就可以创建局部会话，局部会话登录方式与单系统登录方式相同，就相当于实现了子系统的本地登录，这时就可以访问对应子系统的资源了。单点登录原理图如下图8。

图8 单点登录原理图

        上图的流程可分为如下：

        a.用户访问系统1的受保护资源时，系统1发现用户未登录（无本地局部会话），将自己的地址作为参数跳转到sso身份认证中心确认当前用户是否登录

        b.sso身份认证中心接收到请求之后发现用户未登录，将用户引导至登录页面（带上系统1的地址），要求用户登录

        c.用户输入登录的用户名和密码提交登录申请（带上系统1的地址）

        d.sso身份认证中心校验提交上来的用户信息，验证成功后，创建用户与sso身份认证中心之间的会话（全局会话），同时创建授权令牌

        e.sso身份认证中心带着令牌跳转回最初的系统1的请求地址

        f.系统1拿到令牌之后，去sso身份认证中心校验令牌是否有效（带上系统1的地址）

        g.sso身份认证中心校验令牌是否有效，校验成功，令牌有效，注册系统1，返回令牌有效

        h.系统1使用这个有效的令牌创建与用户之间的会话（局部会话），返回受保护资源

        上面就是所有子系统均未在sso身份认证中心验证过的初次访问受保护资源的流程，下面是sso身份认证中心已经认证了用户时访问另一系统的受保护资源的流程：

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

        j.系统2发现用户未登录，参数中带上自己的地址跳转至sso身份认证中心去验证当前用户是否已认证

        k.sso身份认证中心发现用户已经登录，带上令牌跳转回系统2的地址

        l.系统2拿到令牌之后，去sso身份认证中心校验令牌是否有效（带上系统2的地址）

        m.sso身份认证中心校验令牌是否有效，校验成功，令牌有效，注册系统2，返回令牌有效

        n.系统2使用这个有效的令牌创建与用户之间的会话（局部会话），返回受保护资源

        在同一个sso身份认证中心中的系统都如上面所诉两种流程进行单点登录。

        用户登录成功之后，会与sso身份认证中心以及各个子系统创建会话，用户与sso身份认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，当局部会话建立之后，用户访问已建立局部会话的子系统的受保护资源时不再通过sso身份认证中心，全局会话与局部会话存在如下的约束关系：

        a.局部会话存在，全局会话一定存在（因为局部会话创建的前提是，全部会话必须首先创建，也就是说先通过sso身份认证中心的验证创建全局会话后才再指定系统创建局部会话）

        b.全局会话存在，局部会话不一定存在（同上说明，sso身份认证中心验证通过后，创建了全局会话，但是没有访问其他系统，其他系统的局部会话此时是不存在的）

        c.全局会话销毁，局部会话必须销毁（这样就可以实现所有子系统和sso身份认证中心会话状态同步）

        （2）单点注销

        单点注销也是单点登录的一部分，单点登录是同时维持会话同步存在，单点注销就是所有子系统的会话都销毁，实现在一个子系统注销，其他系统也同时注销的效果（sso身份认证中心会一直监听全局会话的状态，一旦全局会话销毁，监听器会通知所有注册系统执行注销操作），具体流程图如下图9。

图9 单点注销流程图

        具体流程说明如下：

        a.用户在客户端向系统1发起注销请求

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

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

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

        e.各个注册系统接收sso身份认证红星的注销请求，销毁局部会话

        f.sso身份认证中心引导用户跳转至登录页面

注：部分图片来自网络