现在的位置: 首页 > 综合 > 正文

基于SOA服务模式的单点登录解决方案

2013年01月11日 ⁄ 综合 ⁄ 共 3238字 ⁄ 字号 评论关闭

 

 

摘要

本文档通过一个基于标准的SOA服务的单点登录信息综合管理平台的开发,解决了分布式系统间的用户认证、权限验证、session超时、单点登出等问题,体现了SOA服务开发面向业务、粗粒度、松耦合方面的特点。

关键字

SSOSCA/SDO标准、SOA服务、单点登录、用户认证、权限验证、EOS6

定义、首字母缩写词及缩略语

SSOSingle Sign-On单点登录

EOSPrimeton EOSTM6.0,普元公司的面向构件的SOA平台

1.1    介绍

在分布式系统中如何实现单点登录和权限验证是很多企业在信息化建设过程中普遍都会遇到的问题。对这个问题,业界也提出了很多的解决方案,比如WebLogicWebSphere都提供了容器级的方案, Yale大学的CAS (Central Authentication Service)这样的开源的解决方案,还有很多企业开发了适用本企业的解决方案。但这些解决方案,都有一个共同弱点,就是用户认证和权限验证不能很好结合,基本上分开解决,单点登录只解决用户认证问题,权限验证都交给各个业务应用独立进行。

SOA成为大势所趋的今天,把用户认证和权限验证包装成SOA服务,在分布式系统中采用SOA服务来认证用户信息,验证用户权限的方案,很好的解决单点登录的认证和权限验证问题。而且基于SOA的单点登录在支持系统松耦合,系统扩展性,灵活性方面都有很大的好处。笔者有幸参加某银行的信息综合管理平台的建设,采用普元公司面向构件的SOA开发平台EOS,很方便的实现基于SCA/SDO标准的SOA服务,实现分布式系统的单点登录和权限验证。

1.2    系统框架

按照规划,信息综合管理平台将为所有的MIS业务应用提供用户认证、权限验证等服务。用户信息、权限信息集中在信息综合平台维护。信息综合管理平台和MIS业务应用可以自由地部署到一台或多台硬件设备,分别有自己独立的数据库。它们的部署图如下:

 


1:系统部署图

对用户而言,信息综合管理平台和业务应用是一个整体。信息综合管理系统需要支持用户单点登录,即用户在客户端要访问业务应用,需要先在信息综合管理系统进行用户登录,登录成功后,用户再访问业务应用时,业务应用判断客户是否有权限访问。如果有权限,则业务应用执行业务逻辑,返回结果给客户。

业务应用权限的信息在信息综合管理平台统一维护,这样有利于集中管理。业务应用能够根据信息综合平台的授权信息进行权限验证。

所以,我们需要在统一用户组织机构、权限管理的基础上,实现信息综合管理平台与各个MIS业务应用的单点登录机制和权限验证机制。

1.3    单点登录机制原理

单点登录主要解决三个问题:单点登录、session超时、单点登出。根据EOS平台的SOA开发方法,从业务问题出发,抽取成服务来解决问题。我们可以用用户认证服务提供单点登录,登出服务提供单点登出功能。用户认证服务由信息综合管理平台提供,登出服务由MIS业务应用提供。

在分布式应用单点登陆处理中,session超时处理都是比较困难的。采用认证服务来处理用户认证方式后,这个问题处理显得很简单。

session超时,如果是业务应用的session超时,则可以通过重新调用信息综合管理平台认证服务来验证用户信息;如果是信息综合管理平台session超时,则需要重新登录。在重新调用认证服务时,客户端通过cookie得到用户的唯一识别号和用户ID,传给认证服务,认证服务可以根据用户识别号是否有效以及和用户ID是否匹配,来决定验证是否通过。

1.3.1   用户认证过程



3 访问业务应用


2 用户认证


用户客户端


1 登陆


5 认证结果返回


4 调用服务,认证用户信息


信息综合管理系统



认证服务


6  应用创建session

2:单点登录的原理图

 

1.         用户在信息综合管理系统的登录页面中,输入用户名和密码。

2.         信息综合管理系统会对用户名和密码进行认证。认证机制可以有很多种,例如自己写一个认证程序,或者使用一些标准的认证方法,例如LDAP或者数据库等等。在大多数情况下,会使用LDAP进行认证。这是因为LDAP在处理用户登录方面,有很多独特的优势。

3.         认证通过之后, 信息综合管理平台会创建用户的session,产生用户唯一标识TICKETID

用户第一次访问应用时候,信息综合管理平台把用户的userIDTICKETID传给业务应用。

4.         业务应用通过单点登录代理SSO Filter拦截用户访问请求,检查业务应用中用户的session中是否有用户信息,如userIDTICKETID。如果有,说明用户已经不是第一次访问业务应用,把请求转到结束。如果session中没有用户信息,则请求信息综合管理平台的认证服务,并传送用户userID,本应用代码appCode,用户唯一识别号TICKETID

5.         信息综合管理平台的认证服务根据userIDTICKETID判断用户是否在信息综合管理平台通过认证。如果用户已经通过认证,则返回用户的相关信息,如用户角色,用户组,用户职务,用户岗位,用户机构。信息综合管理平台记录用户的userIDappCode信息供用户注销时候使用。如果用户还没有在信息综合管理平台通过认证,则转到登录页面进行用户登录。

6.         业务应用得到认证通过的信息,创建用户的session,初始化用户session,在session存放用户的相关信息。以后再有用户请求访问业务应用,业务应用就不用再请求信息综合管理平台的认证服务。

 

   为了保证系统安全,在信息综合管理平台和业务应用间传递的用户名和TICKET用密文传送,即信息综合管理平台把信息用公共的密钥加密,业务应用收到密文,采用和信息综合管理平台公共的密钥把密文解开得到信息。

 

1.3.2   用户注销过程

用户需要登出系统时,在信息综合管理平台选择的注销功能,开始注销过程:

1.         首先在信息综合管理平台从用户session中得到用户曾经访问的业务应用代码即appCode

2.         根据业务应用代码对用户已经认证的应用,循环调用各个业务应用的登出服务。

3.         业务应用在收到服务调用后注销该会话。

4.         循环调用各个业务应用的登出服务完成后,信息综合管理平台注销用户session

最终是用户在信息综合管理平台上的会话失效,从而使得用户在信息综合管理平台上的会话及所有参与SSO的应用上的会话均已失效,单点登出即全部完成。


业务应用


登出服务

Client


业务应用


登出服务

 


2  注销请求


 


用户客户端


1 登出


3  应用注销


4 平台注销


信息综合

管理系统


2  注销请求


3  应用注销

3:单点登出原理图

1.3.3   权限服务

在很多单点登录的解决方案中,并不提供权限验证的功能。一般权限验证都还是放在各个业务应用进行,最多只是在统一登录平台验证一下用户有没有权限进入业务应用。

我们用SOA服务来解决权限验证问题,就显得很容易。

各个业务应用在启动的时候通过调用权限信息服务从信息综合管理平台获取应用的权限角色的信息,把信息放在应用的缓存。用户单点登录成功后,用户认证服务会把用户的角色信息返回给业务应用,放在业务应用用户的session中。当用户访问业务应用资源时,通过用户session的角色信息在缓存中找到角色对应的资源权限信息,从而判断用户是否有访问业务应用资源的权限。

当信息综合管理平台的权限信息有变化,则信息综合管理平台会调用业务应用的一个更新服务来刷新业务应用的权限信息的缓存。这样就保证应用缓存的实时性。

权限服务的示意图如下:

4:权限服务的示意图

1.4    服务的架构

本解决方案中主要有用户认证服务,登出服务,权限数据服务。服务之间的调用关系如下图, EOS平台提供ESB的机制,应用把SOA服务在ESB的注册中心注册,各个应用就可以通过查找获取所需的服务。

抱歉!评论已关闭.