基于Cookie单点登录策略的缺陷和相对理想的设计（来自网络）

基于Cookie单点登录策略的缺陷和相对理想的设计

缺陷

1）客户端不得不启用Cookie

Servlet规范规定一个用户只有一个Session，要求Web容器用一个唯一的键值来对该Session作对应，然而HTTP 请求却是没有状态的。客户端如何保持这个键值呢，一种方法是用Cookie来保存，要是Cookie在客户端被Disabled了，那就只能URL重写

 

2）必须得解决Cookie跨域的问题

 这就要求各个服务器统一域名方式

 

3）必须在客户端或者在某个DNS服务器上配置域名映射

   直接用IP访问是不行的，要是在客户端配置域名映射那将会非常麻烦

 

4）要是不用SSL传输等来加强安全，用户名和密码等存在Cookie中的信息将有可能给截取

 

相对理想的另一设计

1） 用户登录通过认证后生成一个在所有应用都是唯一的ticket，这个ticket只能生效一次且有过期时间，有效时间与对应的Http Seesion的有效时间一样。同时生成一个SSOSeesion，这个用之前生成的唯一ticket对应。

2） 这个SSOSession用来保存相关的用户信息

3） 当用户首次成功登录后，所有应用都能获悉该ticket和SSOSession。

4） 当用户从当前应用访问其他应用时传输的是ticket而不是用户名和密码之类，更好点应该用Http Post方式提交请求

5） 当用户以SSO方式登录成功后，ticket应该被更新，旧ticket应该被立即失效，所有服务器上的旧ticket对应的SSOSession也应失效

6） 用户当前HTTP Session被invalidated时，所有服务器上同一SSOSession也应该同时被Invalidated；同样，登出时也一样

7） 为了更好的安全性，在认证阶段也需要HTTP SSL Transport

 

 

接口

• SSOSession                                 单点登录会话
• SSOSessionContext                   单点登录会话上下文
• ClusterContext                            集群上下文
• ClusterEventSource                   集群消息源
• ClusterNotification                   集群消息

SSOSessionContext需要跟踪所有会话。它继承ClusterContext，ClusterEventSource，这样它就有了集群的能力。

让我们考虑一下应用的场景：
存在应用A和B，用户X先是成功登录A，之后从A转跳到B。B发现自己没有A的登录会话，
于是发出一个集群消息请求会话支援。A收到消息后回应B。最后X成功登录B。

当然，这样的设计存在很多的难点，例如如何进行集群消息回应，更新SSOSession。怎样确定Peer也没有所请求的SSOSession等。
这些都是一些集群需要考虑的问题。

幸运的是，我们可以选择一些开源的集群实现JBoss Cache就是其中之一。要是有了这样的集群实现上面的三个Cluster开头的接口就可以省略了。

转载于:https://www.cnblogs.com/cao-zone/archive/2009/09/01/1558280.html