多站点单点登录(SSO)设计 (转)

这是一个老话题了，当前各门户一般也都实现了多个业务之间的单点登录。下面根据我经历过的项目，谈一下我自己的看法。

 

为什么需要单点登录：

 产品刚上线时，一般由于用户量少，所有的功能都放在一起，一般也不需要具体的单点登录。随着用户量和业务发展的需要，要求逐步将产品按功能或性能分为相应独立的站点，并分开部署，这就需要在各个站点之间进行单点登录，以达到用户一次登录，就可以使用多个站点。

 

单点登录的实现：

简单方法： 在同一个域内的站点，可以简单的通过共享Cookie（将登录用户名存放Cookie中）来实现单点登录。这种方法实现简单，安全性方法可以通过将Cookie值加密方式加强，但对不同域下及不同开发语言下（如A站点C#，B站点C）实现麻烦。

 

推荐方法：建立统一的认证中心，认证中心提供：

　　1、用户登录认证（认证用户名和密码），如果成功，返回表示本次登录的登录Token

　　2、登录Token认证（认证Token是否正确），如果成功，返回当前登录的用户名

　　3、延长Token有效期

　　4、退出（使Token失效)

认证中心独立于各个站点，单点流程一般场景如下：

　　1、用户在站点A输入用户名和密码点击登录

　　2、站点A将用户名和密码转发给认证中心进行认证，认证中心返回Token

　　3、站点A将当前登录用户和Token存入Session（或Cookie)

　　4、在站点A上点击连接访问站点B，通过URL参数方式，将Token带给站点B

　　5、站点B将Token转交到认证中心，认证正确，返回当前用户名。

　　6、站点B将当前登录用户和Token存入Session(或Cookie)，完成登录流程

 这样的设计下的Token，还可以用在异步使用Ajax去访问服务器端的接口（接口可能独立部署在不同的站点下），这样只需要带上Token，服务器端的接口认证Token通过后，直接返回这个登录用户的相应用户信息。

 

 安全性考虑：

 　　1、用户登录认证接口，可增加认证频率、认证IP等限制，防止暴力攻击

　　2、Token其实就是一串表示本次登录的唯一字符串，可以生成字符串时，增加摘要信息。如Token的组成为：A+MD5(A+PWD) 的方式，A为随机生成的GUID，这样在验证Token时，就可以直接通过算法来验证合法性，只有算法验证通过后，再进行下一步的操作。

 

以上只是从整体上描述统一认证的设计，中间还有很多细节没有描述出来，需要了解的我们可进一步讨论。

 下一篇，准备写一下认证中心内部，如何实现分布式认证系统，支持高并发、防攻击等方面内容。

------------------------

转发请保留出处。谢谢

 

 

 

引用

Galactica：
太危险了,你的Token是可以被截获的,这样就可以通过携带该Token访问你的任意站点.

如果是金融领域,还是耐心学习下 WS-Federation .

呵，我的项目不是金融领域。因为Token是有一定时效的，不过这个设计上确实如果Token在传输过程被截获，就可以使用用户身份登录了。
这个设计在安全上的前提是用户的信息传输是安全的，假设Token被截获了，我想其它信息也同样会被截获，除非所有站点都使用https。
我想这样的设计，用于一般门户网站是可以的。

　回复　引用　查看