基于Spring的简易SSO设计

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

1、组件图

基于Spring的简易SSO设计

主要由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、部署图

基于Spring的简易SSO设计

3、SSO Client Filter的序列图

verify token(A)

基于Spring的简易SSO设计

解释:

当用户要访问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)

基于Spring的简易SSO设计

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)

上一篇:HDU 1269 裸奔的强联通分量


下一篇:POJ3723最小生成树