基于Spring的简易SSO设计

通常稍微规模大一些的企业，内部已经有很多的应用系统，多个系统整合首先要解决的便是“统一登录（SSO）”问题，之前写过一篇 利用Membership实现SSO（单点登录） ，java环境下已经有一些开源的成熟sso项目（比如CAS），但如果觉得CAS太麻烦，想自己再造轮子重复发明一个，可以参考下面的思路：（仍然是基于Cookie的实现，只不过安全性上略有加强，cookie端存放的token标识，不再与用户名、密码等这些敏感信息相关）

1、组件图

主要由3大部分组成，

1.1 SSO Client Filter 类似Asp.Net中的HttpMudule，用来拦截client webapp的所有请求，如果发现Cookie中没有已登录的token标识，则将请求重定向到sso 站点的login页面；此外，它还用于接收SSO登录成功后返回的token标识

1.2 SSO App 即SSO的主站点，提供统一的登录认证，并将认证后的token返回给Client WebApp；以及验证Client WebApp发送来的token是否合法。

1.3 Token Store ，用于存放所有当前登录成功的token-user的映射关系，通常是一个key-value的hash结构，通过token（key），可找到相应的用户（value）关键信息（比如：用户名等），物理上，可用cache server/nosql db等轻量级的产品实现。

 

2、部署图

 

3、SSO Client Filter的序列图

verify token(A)

解释：

当用户要访问Client Website中的某个页面时，该请求首先被SSO Client Filter拦截，然后按以下流程处理：

1. 先从cookie中查找token标识

2. 如果没找到token

3. 直接重定向到sso的login页面，并在returnURL参数中，将请求页面传递给sso

3.1 登录成功后，生成一个token字符串，然后将token-user info的映射关系，存入token server

3.2 同时重定向到Client Website登录前的页面，并在url中附加一个token参数

3.2.1 Client Website收到返回的token url参数后，写入Cookie

3.2.2 将token参数从url中去掉，重定向到登录前的请求页面(即：returnURL)

 

转入下面的处理： 

verify token(B)

1.再次从cookie中查找token

2.如果找到，则请求sso site验证token的合法性（因为cookie中的token有可能是伪造的，或者已经失效），并带上returnURL(以便验证通过后，能重定向到用户需要访问的页面)

3 sso收到请求的token后，到token server中验证真伪（带上当前请求页面地址，做为returnUrl附带在url参数中）

4 token server返回验证结果

5 如果校验失败，则跳转到登录页面，要求重新登录（带returnUrl）

6 如果验证通过，返回成功标识

7 子站点拿到成功标识后，大功告成，剩下该干啥干嘛（即：正常执行页面上的常规处理）

验证通过后，再访问其它页面时，因为本地cookie中已经有token标识，所以将直接执行 verify token(B)处理。

 

性能分析：

从前面的分析可以看出，即使第一次认证成功后，后续的每个页面请求都要到SSO上验证token的真伪，这样如果并发用户比较多，SSO的压力略大，可以在client website中增加二级缓存，首次验证通过后，将token-user info的映射关系，存入Client Website自己的缓存中，这样后续其它页面验证token时，直接到client website的cache中验证即可，但这样做的前提是client website中的token cache过期时间一定要小于sso token server中的过期时间，否则SSO Token Server中的token已经失效，但是client website中的token仍有效，就失去验证token真伪的意义了。另外，这样处理后，性能虽然提高了，但安全性从理论上讲，将所有折扣。

 

安全性分析：
token的生成算法很关键，不要与用户名、密码、用户角色等这些敏感信息相关，要保证生成的唯一字符串没有实际业务意义（比如：可用uuid/guid之类），同时若cookie中token被窃取，为了将危害降到最低，每次token验证成功后，最好重新生成新的token，类似手机动态密码一样，用过即换。

 

与Spring的关系：

讲了半天，似乎没看到任何Spring的影子，以上其实是SSO的通用思路，技术上适用于任何主流web技术，Spring-Security可以很容易实现SSO的用户Form Login登录认证，而Token Server可以用Spring-Cache来实现，至于SSO Client Filter、Client Website，Spring-MVC/Servlet Filter可以轻松搞定。

 

如何扩展到c/s应用

虽然SSO在很多情况下，用于整合web子系统，但只要略加改造，c/s应用其实也可以套用这个思路，比如：可以指定硬盘上某个xml文件(或windows注册表中自己新建一个项)用来保存token（相当于浏览器的cookie存储token），c/s的每个窗口统一继承至某个父窗口，在父窗口中，每次打开时，检测该xml中是否有token（相当于sso client filter所做的事情），如果没有，则弹出登录窗口，将用户名、密码参数，发送到sso进行认证（相当于重定向到sso的login页面认证），认证成功后，将服务端返回的token写入本地xml（相当于sso client filter接收token）