1 背景
在网站建设的过程中,多个应用系统一般是在不同的时期开发完成的。各应用系统由于功能侧重、设计方法和开发技术有所不同,也就形成了各自独立的用户库和用户认证体系。随着网站的发展,会出现这样的用户群体:以其中的一个用户为例,他(她)使用网站的多个应用系统,但在每个应用系统中有独立的账号,没有一个整体上的网站用户账号的概念,进入每一个应用系统前都需要以该应用系统的账号来登录。这带给用户不方便的使用感受,用户会想:既然我使用的是同一个网站上的应用,为什么不能在一次在网站上登录之后不必再经过应用系统认证直接进入应用系统呢?用户的要求我们称之为 "单点登录"。
![]() |
图 1.1 网站用户要求单点登录 |
2 分析
在多个拥有各自独立的用户体系的应用系统间实现单点登录,我们要考虑以下的问题:
- 单点登录系统的实现在各应用系统都采用B/S模式这一前提下进行。
- 需要在各应用系统间统一用户认证标志,用户登录后可以得到用户令牌,各应用系统认可统一的用户令牌。
- 用户令牌应当是安全加密的,并且要限定时效期。
- 由于每个应用系统都有自己的用户库,一个用户可能在不同的应用系统中使用不同的账号,因此每个要使用多个应用系统的用户要设置一个统一的用户账号并以此账号进行单点登录,该账号与该用户在各应用系统中的一个账号形成映射关系。
- 各应用系统可能属于不同的域,因此要实现跨域的单点登录。
- 已经上线运行的应用系统需要进行改造来支持单点登录,正在开发的应用系统则可以在开发阶段增加对单点登录的支持,但应用系统之间应该是松耦合。
- 由于各应用系统往往都已经处于稳定运行期,单点登录系统的实现应该对各应用系统的登录认证体系冲击最小,各应用系统原有的登录流程依然可用。
- 一些应用服务器平台虽然提供对单点登录的支持,但要求应用系统用户认证的设计符合其规范,这对已经处于运行期的应用系统来说难以实现。
3 设计
以下是系统的整体设计结构:
![]() |
图 3.1 系统结构图 |
3.1 单点登录管理应用
我们首先设计单点登录管理应用:
![]() |
图 3.2 单点登录管理应用 |
用户在其中注册一个单点登录账号,然后针对每个应用系统绑定一个该应用系统中原有的账号,并维护这些注册和绑定信息。绑定的过程需要单点登录管理应用服务器到应用系统服务器上验证用户提供的该应用系统中原有账号和密码,应用服务器均以相同的Web Service接口提供该功能支持。
3.2 用户单点登录流程
之后以用户单点登录管理应用和令牌传输识别的标准来实现用户单点登录流程。
1、用户访问应用系统。
图 3.3 用户单点登录流程 - 步骤一
2、应用系统如果检查到用户没有在自己的服务器登录,则将用户请求重定向到单点登录服务器上。(使用重定向就可以处理各服务器跨域的情况)
图 3.4 用户单点登录流程 - 步骤二
3、单点登录服务器检查到用户已经单点登录(如果用户没有单点登录则要求用户登录,登录标志存储为客户端浏览器的Cookie),找到该用户在相应应用系统上绑定的账号。
图 3.5 用户单点登录流程 - 步骤三 4、单点登录服务器根据第三步的结果生成用户令牌,重定向回应用系统。
图 3.6 用户单点登录流程 - 步骤四 5、应用系统接收统一格式的用户令牌,取得用户在本系统上的登录账号,将用户在本系统上状态置为登录,返回用户请求访问的页面。
图 3.7 用户单点登录流程 - 步骤五
如果用户在访问应用系统之前已经在单点登录服务器上登录过,第二步到第四布对用户来说就是透明的,用户感觉只是向应用系统发出了访问请求,然后得到了页面反馈。
4 实现
(略)
5 总结
本方案设计的用户单点登录系统做到了:
- 真正了实现单点登录、全网访问,方便用户的使用过程。
- 各系统之间耦合度低,应用系统的改造不破坏其固有流程和结构,整个系统的实施过程安全平滑。
- 统一了单点登录服务器到应用服务器的用户认证信息访问标准,统一了令牌安全加密的传输和识别标准,为将来更多应用系统提供了统一的单点登录框架。
- 整合了过去分散在各应用系统中虽然有内在关联却难以判别的用户信息资源,为更进一步的用户个性化服务打下了基础。