单点登录的相关问题？

为什么需要单点登录？

1）提高用户效率

原因：用户不必为多次登录而困扰，用户不必记住很多id和密码，用户忘记密码并求助支持人员的情况减少

2）提高开发人员效率

原因：sso为开发人员提供了一个通用的身份验证框架，实际上sso机制是独立的，开发人员不必为了身份验证而操作，只需对应用程序的请求附带一个用户名，身份验证即可完成

3）简化配置

原因：如果应用程序加入了单点登录协议，应用管理账号的负担就会减轻，简化配置的程度取决于应用程序，因为sso只处理身份验证，因此，应用程序仍然可能需要设置用户属性(比如用户访问特权)

单点登录来源：

1.早期的单机部署：web单系统应用

早期开发web应用都是把所有的包放在一起打成一个war包放在tomcat容器来运行的，所有的功能，业务，后台管理，门户管理都是由这一个war包来支持的，这样的单应用称为巨石应用，因为不好扩展和拆分。

在巨石应用下,用户的登录以及权限就显得十分简单,用户登录成功后,把相关信息放入会话中,HTTP维护
这个会话,再每次用户请求服务器的时候来验证这个会话即可,大致可以用下图来表示：

 验证登录的这个会话就是session,维护了用户状态,也就是所谓的HTTP有状态协议,我们经常可以在浏览
器中看到JSESSIONID,这个就是用来维持这个关系的key

2.分布式集群部署

由于网站的访问量越来越大，单机部署已经是巨大瓶颈，才有后来的分布式集群部署

扩展：redis3.0之后才加入的redis集群模式，实现分布式存储数据，对数据进行分片，实现将不用的数据分布在不用的master节点上，解决了海量数据存储问题

引用集群的概念：单应用可能重新部署在3台tomcat以上服务器，使用nginx来实现反向代理，此时，这个session就无法在这3台tomcat上共享，用户信息丢失，所以要考虑多服务器之间的session同步问题，这就是单点登录的来源。

单点登录的实现方案：

单点登录的实现方案，一般就包含：Cookies，Session同步，分布式Session方式，目前的大型网站都
是采用分布式Session的方式。我先从cookie的实现谈起，你就能很清楚的知道为什么需要分布式
session方式实现单点登录。

1.基于Cookie的单点登录

使用cookie作为媒介，存放用户凭证。用户登录父应用后，应用返回一个加密的cookie，当用户访问子应用是，携带这个cookie，授权应用解密cookie并进行校验，校验通过后则登录当前用户。

不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑：
      1) Cookie不安全
      2) 不能跨域实现免登

对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露，攻击者通过伪造Cookie则可以伪造特定用户身份，这是很危险的。 对于第二个问题，不能跨域实现免登更是硬伤。所以，才有了以下的分布式session方案

2.分布式session方式实现单点登录

流程运行

1）用户第一次登录时，将会话信息存入分布式session

2）用户再次登录时，获取分布式session,是否有会话信息，如果没有则跳到登录页

3）一般采用cache中间件实现，建议使用redis，因为它有持久化功能，方便分布式session宕机后，可从持久化存储中加载会话信息

4）存入会话时，可设置会话保持时间，比如设置5分钟，超过后自动超时，结合cache中间件实现分布式session，可以很好的模拟session会话.

总结

实现单点登录说到底就是要解决如何产生和存储那个信任，其他系统如何验证这个信任的有效性

       存储信任

       验证信任

存储信任建议采用分布式文件存储redis实现