单点登录（sso）入门

单点登录的英文名叫做Single Sign On，简称SSO。

在以前，一般我们就单系统，所有的功能都在同一个系统上。

后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。

比如阿里系的淘宝和天猫，很明显地我们可以知道这时两个系统，但是你在使用的时候，登陆了天猫，淘宝也会自动登陆。简单来说，单点登陆就是在多个系统中，用户只需要登陆一次，各个系统即能感知到该用户已经登陆。

单系统登陆

众所周知，HTTP是无状态的协议，这意味着服务器无法确认用户的信息。于是乎，W3C就提出了给每一个用户都发出一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。

如果说Cookie是检查用户身上的通行证来确认用户的身份，那么Session就是通过检查服务器上的客户明细表（通行证列表）来确认用户的身份的。Session相当于在服务器中建立了一份客户明细表（通行证列表）。

因为HTTP协议是无状态的，因此Session不能依据HTTP连接来判断是否是同一个用户。于是服务器向用户浏览器发送了一个名为JessionId的Cookie，它的值是Session的id值，然后Session就可以根据Cookie来识别是否是同一个用户。

一般的单系统实现登陆功能都是以下几个步骤：

1.登陆后，将用户信息保存在Session对象中。如果在Session对象中能查到，说明已经登陆；如果在Session对象中查不到，说明没有登陆（或者已经退出登陆）。

2.注销（退出登陆）时，从Sessoin中删除用户的信息。

3.记住我，请求配合Cookie的发送。只要Session还没有失效，即使在关闭浏览器后，重新打开浏览器还能保持登陆状态。这一步骤也就是身份校验，通常使用拦截器来实现。

多系统登陆的问题与解决方法

Session共享问题

单系统登陆功能主要是用Session保存用户信息来实现的，但是多个系统就可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Seesion和系统B的Session就存在一个共享的问题。

解决系统之间Session共享问题有以下几种方案：

1.Tomcat集群Session全局复制（集群内每个Tomcat的Session完全同步），但是这种方案会影响集群的性能，一般不建议。

2.使用反向代理服务器，将请求的IP根据Hash映射到对应的机器上，这样的话同一个IP地址的请求会一直被转发到同一台服务器上。常见的解决方案就是使用Nginx作为反向代理服务器，并使用其ip_hash负载均衡策略。这种方案可能会因为服务器承受不住高并发而宕机导致丢失大部分的Session数据，因此也不建议这么做。

3.把Session放到Redis缓存中，各个服务器读写同一个Redis缓存实现Session的共享。Redis的性能好，吞吐量大，还提供持久化到磁盘的功能，一般推荐使用这个方案。

Cookie的跨域问题

当我们请求www.yanggb.com的时候，浏览器会自动把www.yanggb.com的Cookie带过去，但是却不会把www.renj.com的Cookie带过去，这时因为域名不同导致的跨域问题。具体地说，这时浏览器的同源策略导致的问题，同源策略不允许JS访问跨域的Cookie，当发送请求的时候需要调用JS去浏览器的Cookie库中获得Cookie，这时候因为Cookie中保存有域名的属性作为识别标签，JS是拿不到非本域的Cookie的。

针对Cookie的跨域问题，主要有几种解决方案：

1.使用Token代替Session。服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来存放到SessionStroage中，此后的请求就把这个Token带上进行身份校验。

2.多个域名共享一个Session，在写入到客户端的时候设置Cookie的domian。

CAS原理

说到单点登陆的话，肯定要接触到CAS。CAS的全称是Central Authentication Service，即中心验证服务，说白了就是一个独立的认证中心。

假定现在有3个服务，一个是www.yanggb.com，一个是www.renj.com，还有一个是www.sso.com，其中的www.sso.com就是认证中心。

1.当用户想要访问www.yanggb.com受限（需要登陆）的资源的时候，www.yanggb.com发现用户没有登陆，就会重定向到www.sso.com认证中心，并将自己的地址作为参数，比如：www.sso.com?service=www.yanggb.com。

2.这时www.sso.com认证服务如果发现用户没有登陆，就会将用户引导至登陆页面。用户使用用户名和密码进行登陆之后，用户与认证中心就会建立一个全局的会话（生成Token写入到Cookie中并保存在浏览器上）。然后认证中心就可以重定向会到www.yanggb.com服务，并把Token携带过去：www.yanggb.com?token=********。

3.接着www.yanggb.com就会去www.sso.com认证中心校验这个Token是否正确，如果正确，则www.yanggb.com服务就会和用户建立局部的会话（创建Session）。

4.接下来，用户想要访问www.renj.com受限（需要登陆）的资源，www.renj.com服务发现用户并没有登陆，就会重定向到www.sso.com认证中心，同样将自己的地址作为参数：www.sso.com?service=www.renj.com。因为之前的用户与www.sso.com认证中心已经建立了全局会话，所以这次www.renj.com重定向到www.sso.com认证中心是可以带上Cookie的。认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，就会重定向到www.renj.com，并把Token携带过去给www.renj.com，重定向的地址：www.renj.com?token=********。

5.最后，www.renj.com就会去www.sso.com认证中心校验这个Token是否正确，如果正确，则www.renj.com就和用户建立局部会话（创建Session）。

实际上，SSO认证中心就类似于一个中转站，这就是CAS的核心思想。

"世界上最残忍的不是逃离，而是近在咫尺却不属于自己。"