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

 

 

摘要

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

关键字

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

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

SSO：Single Sign-On单点登录

EOS：Primeton EOS^TM6.0，普元公司的面向构件的SOA平台

1.1    介绍

在分布式系统中如何实现单点登录和权限验证是很多企业在信息化建设过程中普遍都会遇到的问题。对这个问题，业界也提出了很多的解决方案，比如WebLogic，WebSphere都提供了容器级的方案， 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，

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

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

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

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的注册中心注册，各个应用就可以通过查找获取所需的服务。

 

 

 

图5：服务总线结构图

1.5    SOA服务的实现

介绍了实现原理，我们来看一下实现的方法。在本解决方案中，我们采用普元公司的EOS平台来开发SOA服务，EOS平台提供自顶向下和自底向上两种方式来开发SOA服务。

自顶向下的开发方式就是先从业务角度出发，规划好服务，然后在实现服务的过程中构造出一个个构件，包括逻辑构件、运算构件、数据库构件等。自底向上的方式则相反，先有数据库构件，逻辑功能构件，在通过一定的组织把他们包装成服务。

在本方案中，我们用EOS自顶向下的方法来构造SOA服务。前面我们已经划分出了三个服务：认证服务；登出服务；权限验证服务。下面我们以认证服务为例子来说明服务的构建过程。

1.5.1   构件装配

我们先在EOS构建装配图中画出我们需要的服务构件，单点登录主要有两个构件装配：服务器端的认证服务（也称认证服务端）和客户端的认证服务（认证客户端）。

认证服务端是部署在信息综合管理平台。认证客户端是部署在信息综合管理平台和业务应用。认证客户端需要通过webservice方式来调用认证服务端提供的远程服务。认证服务器端的用户认证服务通过绑定webservice方式提供远程调用服务。认证客户端是提供给业务应用本地调用的服务。

认证客户端和服务端的构件采用EOS的逻辑构件来实现。

构件装配图如下：

 

                                                             图6：构件装配图

1.5.1.1             认证服务器端构件信息

认证服务器端构件定义了一个远程认证的接口，输入参数是需要验证的用户信息，如用户名，密码，应用代码，已登录用户的唯一识别号。对他们的约束如下：

l         用户名和应用代码为必须有参数。

l         密码和已登录用户的唯一识别号为可选参数，两者必须要有一个。密码是用户第一次验证需要提供的，已登录用户的唯一识别号是已经验证过的用户需要提供的，一般是为了应用session超时后调用认证服务时需要提供的。

l         系统会根据参数不同进行不同校验：如果有已登录用户的唯一识别号，先进行已登录用户的唯一识别号校验，不通过时如果有密码，会进行用户名密码校验；没有已登录用户的唯一识别号时，进行用户名密码校验。

认证接口的返回参数是一个数组，包含认证是否成功，如果成功，则还包含用户的相关信息，如用户基本信息，用户组，用户岗位，用户角色，用户所属组织信息。

认证接口的参数都是符合SDO2.1标准的SDO对象，所以只要符合标准的调用，都能正常工作。

 

图7：认证服务器端构件信息

1.5.1.2             认证服务端绑定成服务

   要让认证服务端能供客户端通过websevice进行调用，还需要把它绑定到webservice服务。如下图：

 

 

图8：认证服务绑定图

1.5.1.3             认证客户端的构件信息

 

认证客户端是提供给业务应用本地调用的服务。认证客户器端构件定义了认证服务的接口，它的接口输入输出和认证服务端的构件是一样的。

认证客户端通过webservice绑定的方式调用了认证服务器端的引用。 如图7构件装配图所示。

业务应用通过调用认证客户端来进行用户认证。

 

 

  

图9：认证客户端的构件信息

 

1.5.2 服务实现

1.5.2.1             认证服务端的服务实现

定义好服务的接口后，需要来进行服务的实现，EOS的逻辑构件服务是用构件的逻辑流来实现。

我们需要定义一个userAuth的构件实现userLoginRemote的逻辑流。逻辑流实现如下图：

 

图10：认证服务实现逻辑流图

在这个逻辑流，我们主要调用了一个运算逻辑：验证TicketID（登录用户唯一标识），两个子业务逻辑流：本地认证和查询用户信息。

本地认证的业务逻辑流图如下：

 

 

图11：本地认证的业务逻辑流图

 

查询用户信息的业务逻辑流图如下：

 

 

图12：查询用户信息的业务逻辑流图

 

1.5.2.2             认证客户端服务的实现

认证客户端的服务主要作用就是调用认证服务端的引用，供本地的逻辑流来调用该服务。所以它的实现比较简单。它也是通过构件的逻辑流来实现的，逻辑流图如下：

 

 

 

 

图13：认证客户端服务实现逻辑流图

 

1.5.3   单点登录逻辑流的实现

 服务都构件好了，现在我们通过一个单点登录的逻辑流来实现信息综合管理平台服务器端和应用客户端的登录逻辑。逻辑流图如下：

 

 

 

 

图14：单点登陆逻辑流图

   逻辑流图从配置中获取是调用本地用户认证还是远程的用户认证：本地认证适用于用户访问信息综合管理平台的情况；远程认证适用于用户访问业务应用的情况，如果远程认证，则调用认证客户端的认证服务。如果是本地认证，则调用用户认证的逻辑流进行认证。

 

1.5.4   认证代理的实现

从用户单点登录原理图上，我们可以看到，在业务应用端需要有有一个单点登录的认证代理用来检查用户是否已经登录，如果没有登录则调用登录的逻辑流来实现登录。这个代理我们采用Filter来实现。它的逻辑图如下：

 

 

 

 

图15：认证代理逻辑图

 

1.5.5   部署

单点登录认证服务的部署如下图。它可以实现非常灵活的登录方式，例如，通过在业务应用配置成本地认证方式，并部署本地认证的逻辑流和查询用户信息逻辑流（图中红色虚框部分），可以实现业务应用保留单独的登录入口，可以脱离信息综合管理平台独立地运行。

 

                                 图16：部署图

2       总结

在本方案中，我们采用SOA的方法来分析企业分布式系统中遇到的单点登陆问题，规划了两个重要的服务：用户认证服务和权限验证服务。用普元的EOS平台方便地构建了基于服务的单点登陆平台。这样的解决方案比其他的单点登陆解决方案在构建松耦合，易管理，符合标准的SOA服务，满足灵活多变的业务应用集成方面有显著的优点。