CN101895555A - 一种基于bpel的安全访问业务集成建模方法 - Google Patents

Abstract

本发明提供了一种安全访问业务集成建模方法，属于信息安全技术领域，该方法针对系统中的安全访问业务，将安全访问业务分为了认证流程、访问控制流程和审计流程，在此基础上，设计了基于BPEL并实施具体的安全访问业务流程，为安全访问业务流程中的认证、访问控制和审计的详细处理流程，提供了相关Web Service构件实现具体的功能，通过BPEL实现安全访问业务与Web Service构件的接口以及业务与Web Service间的交换信息。业务集成者通过BPEL可以很方便的将已有的信息安全构件和Web Service进行集成，快速的开发出一套适合应用的安全访问业务流程；另外，也可以对业务流程中的Web Service进行敏捷的替换，提高开发效率。

Description

一种基于BPEL的安全访问业务集成建模方法

技术领域

本发明属于计算机技术和信息安全领域，涉及安全服务构件的组装开发模式，更确切体现为一种基于BPEL(Business Process Execution Language)的安全访问业务集成建模方法。

背景技术

长期以来，多数实际应用系统的安全功能模块基本上采用内嵌业务模块的方式开发实现，安全组件和业务组件耦合度过高，无论是过程式编程还是面向对象式编程，都无法避免两者交互关系繁杂、功能逻辑抽离性差的特点；另外，安全系统涉及认证、授权、访问控制和责任认定等领域，现有的集中开发模式没有从软件形态、逻辑形态以及最后的物理形态上对安全组件进行进一步构件化分离，造成部件功能划分模糊重叠，不易开展安全功能专有评测，二次开发代价高、周期长、风险大。随着分布式网络技术的应用和企业系统对资源集成和流程自动化的持续关注，传统安全开发模式、安全产品形态都无法满足复用性、灵活性、开放协作性等高层次的安全需求；同时，网格技术、Web Service、SOA、云计算等新兴应用架构更是加速了安全软件形态变化的趋势，使其向协作型、可插拔的中间件模式转变。近年来，国际上已涌现出一批具有技术特色、在学术界和产业界都产生较大影响的安全中间件项目。

耶鲁大学提出的统一认证服务CAS是一个比较典型的认证与应用分离的解决方案。它提供了一套独立的，适用于分布式环境下的，兼容各种异构平台的单域认证系统。它在需要保护的应用系统中插入CASH客户端插件，由CAS服务器端作为认证中心，通过票据验证为多个应用系统提供统一认证服务，让用户可以一次登录多次访问。CAS的不足在于过分依赖专有认证协议(源自Kerberos思想)，对认证协议过程缺乏高层封装性，从而不利于引入其他新型协议和认证方式，定制能力和延展空间有限。

Internet2/MACE和IBM联合开发了Shibboleth中间件系统，旨在为多组织(主要是大学和科研机构)间建立信任关系和Web资源共享提供支撑平台。其自身并不具有认证功能，而是结合CAS用来提供身份管理功能，利用安全断言标记语言SAML实现跨组织的单点登录，并具有隐私保护解决方案。其不足之处在于支持的认证模式比较单一，扩展开发需要从代码级别做起，同时配置复杂烦琐，不利于使用。

PERMIS是英国Kent大学面向特权管理基础设施而开发的中间件项目，该项目采用基于角色的访问控制模型，通过颁发属性证书的方式对用户权限和访问策略进行管理集成，主要关注分布式环境下用户属性(主要是角色属性)的可信发布问题。其不足之处在于管理机制缺乏松耦合性，不符合构件化的系统开发模式，不支持Web Service等远程调用封装机制，策略制定采用的是专有机制，缺乏对多种应用场景的广泛的支持，难以提供通用的访问控制接口。

Cardea是美国NASA开发了安全授权项目，主要负责组织内用户的访问控制判定，实质是针对业务应用的授权网关，实现过程采用了SAML传输标准和XACML策略制定标准。其不足在于缺乏与各种跨域认证机制进行有效结合的接口和标准，没有考虑将认证授权审计实现整合的应用场景，无法搭建一个完整的安全访问实施平台。

以上项目虽然采用了面向专有安全功能开发的中间件形式，但其内部构件化和可替换性还处在粗粒度、层次单一的发展阶段，无法适应企业应用对安全功能定制的裁剪性和敏捷性需求，基本上没有提供面向安全开发人员或者业务设计人员进行多次开发、自由组装的平台和方法。

还有一些旨在提供基础性安全技术的开发包，例如Bouncy Castle Crypto、Crypto++、JSBN Crypto、IAIK Crypto等，这些项目可以提供全面丰富的密码算法具体实现、公钥/属性证书生成器、密码学相关数学工具，已经在很多实际系统作为安全基础设施大量应用，但其两个基本不足在于：开发包内部结构仍然比较复杂，即使面向专业人员的学习曲线仍然较高；缺乏构建上层安全集成服务的组装模式和开发模版，不能提供直接面向业务安全的功能接口，后期的开发量仍然较大。而且现有的应用系统的安全的研究往往是先确定系统需要哪些安全功能来保证系统的安全，然后研究具体安全功能的实现，很少会关注具体的安全事务流程，单独的安全功能的安全是不足以保证应用系统业务的整体安全性。

发明内容

为了解决现有技术中存在的问题，本发明提出了一种新的安全访问业务建模方法，提供直接面向业务安全的功能接口，可以保证应用系统业务的整体安全性。

为了实现本发明的目的，采用的技术方案概述如下：一种基于BPEL的安全访问业务集成建模方法，其步骤包括：1)从已有的应用业务中提取出安全访问业务，按照安全处理过程依次包括安全认证流程、授权与访问控制流程、审计与责任认定流程，并且通过集成的Web服务构件提供安全访问业务流程需要实现的功能；2)安全访问业务通过BPEL-receive模块接收用户对于安全访问业务流程的调用请求，通过BPEL-Assign模块设定认证状态获取服务构件的输入参数变量，通过BPEL-Invoke模块，调用认证状态获取服务构件，查看用户的认证状态；3)对经过认证的用户，通过BPEL-Assign模块设定认证断言服务构件的输入参数变量，然后通过BPEL-Invoke模块调用认证断言服务构件为认证结果生成一个断言，最后从认证断言服务构件的返回值中获取认证断言，结束认证处理流程；4)通过BPEL-Assign模块设定授权评估服务构件的输入参数变量，通过BPEL-Invoke模块调用授权评估服务构件，用来评估可否对用户访问请求授权；5)通过BPEL-Assign模块设定审计记录服务构件的输入参数变量，通过BPEL-Invoke模块异步调用审计记录服务构件；通过BPEL-receive模块，接受审计记录服务构件的返回值；6)通过BPEL-Assign模块设定安全访问业务流程的输出参数变量，通过BPEL-Reply模块，将值返回给安全访问业务调用者，完成整个安全访问业务集成建模。

所述步骤3)对未经认证的先进行本地认证，其步骤包括：2-1)通过BPEL-Invoke模块同步调用认证域选择服务，获取用户所属域；2-2)通过BPEL-Assign模块设定用户所属域，通过BPEL-Invoke模块同步调用用户所属域上的认证服务；2-3)认证服务通过BPEL-Pick...OnMessage模块根据用户选择的认证方式，通过BPEL-Invoke调用认证服务构件，并获取认证结果。

所述步骤2-1)获取用户所属域为外域，通过BPEL-Invoke调用身份联合服务获取用户假名；所述步骤2-3)认证服务构件包括：口令认证服务、证书认证服务、基于身份的认证服务和令牌认证服务。

所述步骤4)通过BPEL-Assign模块设定输入参数变量后，通过BPEL-While模块循环处理策略集中的策略，直到所有策略都处理完毕，具体包括：4-1)通过BPEL-Invoke模块调用策略缓存服务，在缓存中检索所需要的策略；4-2)如果检索到策略，通过BPEL-Invoke模块调用属性缓存服务，在缓存中检索所需要的属性；4-3)如果检索到属性，根据策略和属性值信息进行访问控制判定，返回判定结果，访问控制处理流程结束。

所述步骤4-2)如果没有检索到策略，通过BPEL-Invoke模块调用策略获取服务，接着通过BPEL-Pick...OnMessage模块，根据系统配置选择策略获取服务，获取匹配的策略。

所述步骤4-3)如果没有检索到属性，通过BPEL-Invoke模块调用属性获取服务，接着通过BPEL-Pick...OnMessage模块，根据系统配置选择属性获取服务，获取匹配的属性值。

所述策略获取服务包括数据库策略获取服务或者文件略获取服务。

所述属性获取服务包括数据库属性获取服务、LDAP属性获取服务或者感知器属性获取服务。

本发明相对于之前的技术的优点：a)松耦合性从以上的描述可以发现，在本发明的业务流程过程中，各组合服务构件间没有实际的联系，只是在业务流程需要的时候发送或者是接收信息，它们之间的耦合性是非常低的。

b)互操作性BPEL业务流程的描述是基于Web Service的WSDL描述，而这个业务流程本身的最终呈现形式也是Web Service，因此，它能够继承Web Service的互操作性。

c)重用性重用性体现在两个方面：一个是集成过程中，具体安全功能实现的构件的重用，另一个是业务流程自身的重用，它可以看成是一个复杂的组合服务构件，可以直接纳入到构件体系中提供给其它业务进行复用。重用性在总体和局部两个方面得到了很好的体现。

d)灵活性当需要对业务流程进行修改时，只需要将相应的组合服务构件引入，更改相应的业务流程与具体的交互信息，然后重新部署此业务流程即可，可以很方便的对流程进行修改，灵活性强。

e)敏捷性业务流程修改并重新部署之后，不需要额外的操作，新的业务更改就会敏捷的反应到实际业务流程中。

f)目标明确业务流程的实施过程是：建模——集成——部署——管理，可以发现，此过程从最顶层的模型出发，是一个从目标出发的自顶向下的过程，此过程可以保证业务实施过程中开发工作与目标的一致性。

g)易于交流业务集成建模是在构件层次之上进行开发，与实际业务结合，将抽象的模型与业务结合，描述接近自然语言，简洁、易懂，能够很方便的用于用户与设计人员，设计人员与开发人员之间的交流。

h)经验积累构件是从经验来判断如何开发和复用，而BPEL从实际业务来判断如何开发和复用，可以从实际业务的实施来积累安全业务开发经验，用于指导构件的开发。

附图说明

图1为本发明总体结构图；图2为本发明安全访问业务流程图；图3为本发明认证服务流程图；图4为本发明访问控制服务流程图；图5为本发明策略获取服务流程图；图6为本发明属性获取服务流程图。

具体实施方式

下面通过具体实施例和附图对本发明作进一步的描述。

信息安全共性构件的开发是从底层基础构件到中层功能设施构件然后到上层的集成服务构件，而业务流程的开发是从上层的业务建模到中层的过程分析然后到底层的服务集成。这是两个不同方向的开发，本发明利用BPEL编排将构件开发与业务流程开发无缝的结合起来，形成完善的安全业务集成建模模式，如图1所示。信息安全共性构件集划分为三个层次，从底向上依次为：安全基础构件技术层、安全功能设施构件层和安全集成服务构件层。通过BPEL安全访问业务流程分析，可以确定安全集成服务构件层的接口，以及需要实现的功能，接口可以通过partner link和服务本身的wsdl描述来体现；至于具体的功能的实现，即如何由安全基础构件和安全功能设施构件来集成实现服务对应的功能在本发明内不做规定，只在下面给出相关的说明。

信息安全共性构件按实现功能的复杂程度划分为基础构件，功能构件和服务构件三个层次。基础构件只实现信息安全过程中某个具体的算法或者定义某种具体的算法结构；功能构件使用基础构件搭建，能够完成一定的功能。将信息安全任务中经常用到的功能封装成为功能构件，方便代码重复使用，以提高代码的利用率。服务构件通常是由多个功能构件或者基础构件搭建而成，可以单独为安全系统提供一种服务。本专利中所说的安全集成服务构件则是指共性构件最上层的服务构件，所说的web服务则是这些服务构件以Web Service的形式提供的安全服务。例如，本专利中的认证服务构件中的公钥证书认证服务构件就会用到PKI基础设施构件，公钥证书构件等功能构件，而公钥证书构件的实现又会用到ASN.1编解码构件，大整数运算构件等基础构件。每个层次上的构件都会对外提供简单地接口，并将复杂的运算过程封装起来，方便外部调用者使用。

本发明从已有的应用业务中抽取并设计了一个完整的安全访问业务流程，这个安全访问业务流程是一个通用的流程，应用系统必须遵循此业务流程以保证系统的相关安全性。本实施例中安全访问业务流程包括安全认证，授权与访问控制，审计与责任认定三大处理流程，如图2所示。在这些处理流程之下，具体集成了域定位服务、认证服务、跨域身份联合服务、断言服务、策略查询服务、属性查询服务、审计记录服务等跨域或单域访问过程中需要的Web Service服务，能够提供一套完整的安全访问业务流程所需的各种功能。此外，通过利用以上Web Service服务所提供的已独立实现的功能，可以根据具体应用场景的不同，利用BPEL添加扩充服务，替换已有的Web Service功能的实现或者是重新设定安全访问业务流程，从底层构件到安全访问流程都可以进行拆分、替换和复用，最大程度的减少了重复开发。

在安全访问业务流程定义过程中，需要根据对外提供的具体功能来定义这个流程中需要的变量。安全访问业务流程实施时用到的不同具体Web服务也都需要明确定义自己需要的输入输出参数。在BPEL流程中，将这些输入输出参数定义为变量，为了方便记忆和使用，变量名都是在流程或者Web服务的名字后面添加一个字段进行标识，输入参数用“Request”来标识，输出字段用“Response”。

例如，整个安全访问业务流程的输入参数为“AccessControlProcessRequest”，输出参数为“AccessControlProcessResponse”。这里的输入和输出参数并不是一个简单的数据，而是一个包含了所有需要的具体数据的。例如，”AccessControlProcessRequest”中可以包括用户名name(string类型)，口令password(string类型)，请求资源resource(anyURI类型)。各个具体Web服务的输入输出参数是根据其功能在实现的时候确定的，会在相应的wsdl接口文件中给出说明。

这里假定对于流程中的每一个访问到的Web服务，都事先定义好了输入和输出变量，在后面可以直接使用。下面介绍安全访问业务流程的具体执行步骤：1.安全访问业务流程通过<receive>模块接受客户输入的数据，将其保存到变量AccessControlProcessRequest变量中，接着要调用AuthenticationStateViewService来查看用户的认证状态。通过<Assign>赋值任务，将AccessControlProcessRequest变量中的name字段赋值到AuthenticationStateViewServiceRequest中的name字段。再通过<Invoke>任务，调用AuthenticationStateViewService服务，用以查看用户的认证状态。由于AuthenticationStateViewService服务为一个同步调用服务，在调用之后必须得到其返回值才能继续执行下一步任务，返回值为变量AuthenticationStateViewServiceResponse，其中包含一个boolean类型的值true或者false，表示该用户是否已经经过认证；2.在调用过AuthenticationStateViewService服务之后，是一个<If>判定任务，这里根据AuthenticationStateViewServiceResponse中的不同认证状态信息形成两个分支。若已经经过认证，则不需要再次调用认证服务，可直接转到后续步骤3；否则，需要对用户进行一个认证过程。

这个认证过程需要执行一些列相关的任务，是一个任务序列，用<Sequence>来表示。在认证过程中，首先需要确认用户身份所在的域信息，所以需要调用LocationService。执行<Assign>，将AccessControlProcessRequest中的name和resource字段传给LocationService服务的输入参数LocationServiceRequest，接着通过<Invoke>同步调用服务LocationService，获得返回值LocationServiceResponse，需要的域信息就包含在这个变量中。

下一步就是调用认证服务AuthenticationEnforceService进行认证的过程。也是通过<Assign>将相关参数name和password传递给认证服务的参数AuthenticationEnforceServiceRequest，然后通过<Invoke>任务调用AuthenticationEnforceService服务，并获得其返回值。该服务的返回值也是一个boolean类型的值，true表示认证通过，相应地，false表示认证没有通过。需要提及的是，这里的AuthenticationEnforceService其内部实现也是一个BPEL流程，名字叫做AuthenticationEnforceProcess，为了使整个安全访问业务流程说明更加清晰，在这里暂时不对其进行详细介绍。后面会单独介绍AuthenticationEnforceProcess。

在进行过认证之后，还需要对跨域的情况进行一下特殊过程地处理。之前在调用过LocationService之后，安全访问业务流程已经得到了用户身份所在的域和访问资源所在域信息。在这里需要对这些信息进行处理。使用一个<If>结构，在其中对两个域信息进行判定，看是否属于跨域信息访问，若是跨域需要执行一个跨域联合的操作序列，若不是跨域访问，则可以省去这一系列操作。

跨域联合的操作序列需要用到跨域身份联合服务FederationService，将用户域身份映射到资源域的身份，该操作序列可以表述为：首先是<Assign>为跨域联合服务输入参数赋值，这个输入参数应该包含用户以及其所访问资源所在的域信息。然后通过<Invoke>同步调用跨域联合Web服务FederationService，在调用过这个服务之后，得到跨域联合服务的返回值FederationServiceResponse，其中包含跨域联合后的用户假名等。

3.在通过上面的认证和跨域联合之后，安全访问流程接下来需要做的就该是生成断言。断言的作用就相当于一个票据，得到断言表示认证过程结束，该用户已经经过认证。生成断言的过程也可以通过调用相应的web服务AssertionService来实现。具体过程如下：首先必须为AssertionService传入参数，同样通过<Assign>任务来完成，传入参数应该包括用户名name和请求资源信息resource。将这两项信息放入AssertionServiceRequest变量中之后，再通过<Invoke>来调用AssertionService服务。由于对AssertionService服务的调用是一个同步调用，所以可以直接得到断言结果，可以是一个String类型的值，包含在变量AssertionService-Response中。

4.接下来调用授权评估服务AuthorizationEvaluationService，用来评估可否对用户访问请求授权。传入的参数中应该包括用户名，请求资源信息。AuthorizationEvaluationService服务的实现是一个BPEL流程，名为AuthorizationEvaluationProcess，其具体内容将在后面单独予以介绍。这里主要说明整个安全访问业务流程中，是怎样将其作为一个服务进行调用的。首先，仍然是<Assign>任务将name，resource从AccessControlProcessRequest中赋值到AuthorizationEvaluationServiceRequest中，然后再通过<Invoke>任务，调用AuthorizationEvaluationService。该服务的返回值同样为boolean类型，表示是否允许授权。

5.接着，要通过异步调用AuditLogService服务记录审计日志。这个服务需要的输入参数为用户名name和请求访问的资源source。调用过程同其他服务一样，先是通过<Assign>任务对输入参数进行赋值，然后再通过<Invoke>任务进行对服务的调用。由于AuditLogService是异步调用，所以在该服务执行完成之后，需要回调其调用者，即安全访问流程。所以在调用完成之后，需要一个<Receive>任务，来接受AuditLogService服务的返回值。

6.最后需要通过<Assign>任务，将需要返回给用户的值，例如访问资源resource等赋值到安全访问业务流程的返回值AccessControlProcessResponse中。然后再通过<Reply>，将值返回给其调用者，完成整个安全业务访问流程。

前面介绍过，在整个安全访问业务流程所调用到的web服务中，有两个服务也是基于BPEL的处理流程。这两个流程分别为AuthenticationEnforceProcess和AuthorizationEvaluationProcess。前者主要是完成认证服务，后者的功能是完成授权评估服务。下面就对它们的处理流程进行分别地介绍。

AuthenticationEnforceProcess是认证流程，属于整个安全访问业务流程的子流程，它封装为一个服务构件对外提供服务。该流程内部其实包含的是具有不同类型的具体认证功能服务构件，根据不同的应用场景可以配置选择不同类型的认证功能，例如基于口令认证或者基于身份认证。

AuthenticationEnforceProcess流程如图3所示，具体步骤如下：1.首先同其他基于BPEL流程一样，执行一次<Receive>任务接受输入参数并将其赋值到AuthenticationEnforceProcessRequesst中，这里的参数中应该包括用户名name和口令password。之后通过<Assign>任务，将参数赋值到具体的认证Web服务的输入参数中去。在这里列举了四种具体的认证Web服务，每种服务通过不同的方法来进行认证，包括口令认证，证书认证，基于身份认证和基于标识认证。在实际应用中还可以根据具体的系统来加入更多其他种类的认证服务。还需要说明的一点是，这里假定可以给所有的认证服务提供统一的接口，那么就可以在上面的<Assign>任务中对其输入参数进行赋值了。如果不能规定统一的接口，则需要在调用之前，对需要调用的Web服务的输入参数进行单独的赋值过程。

2.通过一个<Pick...OnMessage>任务，根据用户提供的信息选择相应的具体认证方式。选择之后就可以通过一个执行序列<Sequence>来完成具体的认证过程了。在这个序列中，由于前面假定在选择认证方式之前就对其输入参数进行了赋值，那么可以直接使用<Invoke>任务来调用相应的服务。这里的调用方法为同步调用，所以可以直接得到认证结果，为boolean类型的值，true或者false。

3.在最后，流程将具体认证服务的boolean类型返回值通过<Assign>任务赋值到返回值AuthenticationEnforceProcessResponse中，然后通过<Reply>任务，将结果返回给其调用者，结束认证流程。

AuthorizationEvaluationProcess是授权评估流程，他也是整个安全访问业务流程中的一个子流程，属于认证过程之后的访问控制过程部分。授权评估流程主要作用是根据系统配置的授权策略和为用户颁发的授权属性来为用户的此次访问过程授权，即决定是否允许用户访问资源，访问过程中有什么样的权限。

AuthorizationEvaluationProcess流程如图4所示，具体步骤如下：1.通过<Receive>来接受流程的输入参数AuthorizationEvaluationProcess-Request，其中应该包括用户名name，请求访问的资源信息resource。

2.接收到输入参数之后，开始执行一个<While>循环过程。使用循环的目的是对策略集中的每一条策略进行处理，直到所有策略处理完成之后，循环才能结束。而每一次的循环过程中都是一个web服务的访问序列，这里用<Sequence>来表示它。在这个<Sequence>中，要执行一系列地操作。但从整体上来看，主要分成两个阶段，一个阶段是策略检索阶段，另一个阶段是属性检索阶段。在下面对其进行详细地介绍。

a)进行策略检索过程，可以把它描述成两个部分。首先是在Cache中进行检索，即调用PolCacheService进行检索。在调用这个服务之前，同其他服务一样，首先使用<Assign>任务进行输入参数的赋值，然后通过<Invoke>任务进行调用。Cache中策略检索服务需要的输入参数为用户名name和访问资源resource。返回结果就是与这个访问相对应的一条策略，若没有检索到，则会返回一条空记录。

b)然后接下来是一个<If>表示的分支结构，它根据PolCacheService是否检索到策略而执行两条不同的分支。若在Cache中检索到了策略，则可以转到步骤c)直接进行属性检索过程了，若没有检索到策略，则会执行一个操作序列<Sequence>，调用一个名为PolRetrieveService的Web服务，这个服务主要功能是在其他存储策略的位置上检索策略。其实现也是一个BPEL流程，这个流程会在后面给出详细说明。调用这个策略检索服务首先也是<Assign>为其输入参数赋值，然后用<Invoke>进行调用。输入参数和返回值类型都跟PolCacheService一致。

c)在前面，PolCacheService或者PolRetrieveService检索到了策略之后，下一步需要进行的是属性检索。首先是在Cache中检索属性，调用名为AttrCacheService的属性检索服务，通过<Assign>为其输入参数AttrCacheServiceRequest赋值，再通过<Invoke>进行调用。这个Web服务的输入参数中包含的应该是策略检索之后得到的策略，其返回值应该是boolean类型的值，表示是否在Cache中检索到对应于策略的属性。

d)紧接着AttrCacheService的是一个<If>分支结构，根据Cache中属性检索的结果来执行不同的后续流程。如果检索到了属性，可以直接进行下一轮While循环，否则得话，必须通过一个执行序列，来调用AttrRetrieveService在其他地方进行属性检索。这个AttrRetrieveService可以根据用户的不同选择，在磁盘或者其他地方进行属性检索。它的实现也是一个BPEL流程，在后面会对该流程进行详细介绍，这里只把它作为一个普通的Web服务来调用。对这个检索服务的调用是通过<Assign>对输入参数进行赋值，通过<Invoke>进行调用的。AttrRetrieveService的输入参数和返回值类型都与AttrCacheService是相同的。输入参数为一条策略，返回值为boolean类型，表示是否检索到属性。

e)若检索到属性，则进行下一轮while循环，否则，根据具体的策略决定是进行下一轮循环，还是直接退出流程。

3.执行<Assign>任务，将授权评估结果赋值到AuthorizationEvaluation-ProcessResponse中，再执行<Reply>将其返回给AuthorizationEvaluationProcess的调用者，完成这个流程。

在AuthorizationEvaluationProcess中，用到两个Web服务PolRetrieveService和AttrRetrieveService是基于BPEL的执行流程，下面将对其内部实现进行详细介绍：PolRetrieveProcess是策略检索流程，他作为一个Web服务构件向外提供服务。流程内部封装了多个具体的策略检索服务构件，能够根据系统配置来决定使用哪一种检索方式来检索授权策略。

PolRetrieveProcess流程如图5所示，具体步骤如下：1.首先，该过程通过一个<Receive>任务接受外部调用者传入的输入参数，其中应该包括用户名name和需要访问的资源resource，然后通过<Assign>赋值给具体调用的策略检索服务。这里假定所有的策略检索服务接口是相同的，所以可以统一对其输入参数进行赋值。否则若有不同的话，也可以在确定了检索类型之后，再对其进行赋值。

2.在对输入参数赋值之后，执行一个<Pick...OnMessage>任务。该任务可以通过接受用户参数，来决定选择使用哪种具体的检索服务。在这里列举两个服务作为例子，比如DB-PolRetrieveService和File-PolRetrieveService，前者在数据库中检索策略，后者在文件中检索策略。检索服务的返回值应该是检索到的策略，可以用多个字符串的组合来表示一个策略。

3.在得到检索服务的返回值之后，通过一个<Assign>任务，将具体检索服务返回值中的策略赋值到检索流程的返回值PolRetrieveProcessResponse中，然后再调用<Reply>任务，将参数返回给其调用者，流程结束。

AttrRetrieveService是授权属性检索流程，它作为一个Web服务构件对外提供服务，流程内部是使用具体的属性检索服务构件实现，封装了多个不同类型的具体属性检索服务构件，根据系统配置来决定使用哪一个进行属性检索。

AttrRetrieveService流程如图6所示，具体步骤如下：1.首先也是通过<Receive>接受外部调用者传入的参数，输入参数中应该包括需要为其检索属性的策略，可以用多个字符串的组合来表示这个策略。在得到输入参数之后，将其赋值给具体的属性检索服务。根据不同的系统，具体的属性检索服务也是不尽相同的，但是在这里假定其具有相同的对外接口，所以可以统一对其进行赋值。如果接口不一致，那么可以将赋值过程下移到确定了具体的属性检索服务之后再进行。

2.然后使用一个<Pick...OnMessage>任务来根据用户提供的信息，选择具体的属性检索服务。这里可以列举几个不同的属性检索服务，例如DB-AttrRetrieveService，Ldap-AttrRetrieveService，Sensor-RetrieveService。同样，对于不同的环境和系统，也可以使用其他不同的属性检索服务。这些服务都是通过<Invoke>任务进行的同步调用。每个服务的输入参数都应该包含要检索属性的策略，而且都应该提供检索结果的返回值。

3.AttrRetrieveProcess流程使用<Assign>将具体检索服务的返回值赋值到自己的返回值AttrRetrieveProcessResponse中，再通过<Reply>任务返回给其调用者，终止整个流程。

最后给出一个基于BPEL的业务集成建模过程，包括以下步骤：a)从已有的应用业务中提取出安全访问业务流程；b)将业务流程按照流程先后顺序依次分解为认证、访问控制、审计三个安全处理过程；c)安全访问业务通过BPEL-receive模块接收用户对于安全访问业务流程的调用请求；其中，业务流程中的认证处理过程负责解决用户认证、跨域认证以及认证断言发布等问题，它主要包括以下几个步骤：d)执行BPEL-Assign指令设定认证状态获取服务请求信息中的用户名name字段；e)执行BPEL-Invoke指令同步调用认证状态获取服务，并根据返回的Response信息，调用BPEL-If指令判定任务，如果是已认证，则跳过以下认证步骤，直接进入访问控制服务流程；如果未认证，则继续以下步骤；f)执行BPEL-Assign指令设定认证域选择服务请求信息；g)执行BPEL-Invoke指令同步调用认证域选择服务为用户提供所属认证域选择，并获取选择结果；h)执行BPEL-Assign指令设定所属域的认证服务请求信息；i)执行BPEL-Invoke指令调用所属域的认证服务，然后与用户交互，获取认证方式、用户认证信息(证书、用户名和口令等)，并执行BPEL-Assign指令设定具体的认证方式的服务请求信息；j)接着执行BPEL-Pick...OnMessage指令任务，根据认证方式执行BPEL-Invoke指令调用口令认证服务、证书认证服务、基于身份的认证服务或者是令牌认证服务，最后将认证域、认证方式、用户假名、认证结果等信息返回本地域认证处理流程；k)本地域认证处理流程调用BPEL-If指令判定任务，如果用户是外域用户，则先执行BPEL-Assign指令设定身份联合服务请求信息，然后执行BPEL-Invoke指令调用身份联合服务，最后从身份联合服务返回值中获取用户假名等相关信息；l)执行BPEL-Assign指令设定认证断言服务请求信息，然后执行BPEL-Invoke指令调用认证断言服务获取用户认证状态信息，最后从认证断言服务返回值中获取认证断言，认证处理流程结束；访问控制处理过程负责解决用户授权、访问控制判定等问题，它主要包括以下几个步骤：m)执行BPEL-Assign指令设定授权评估服务请求信息，主要包括用户名name、访问资源resource、认证断言等；n)执行BPEL-While指令循环处理策略集中的策略，直到所有策略都被处理完毕；o)执行BPEL-Assign指令设定策略缓存服务请求信息，然后执行BPEL-Invoke指令调用策略缓存服务返回当前缓存的策略，并根据查询结果执行BPEL-If指令任务，如果未找到策略，则调用策略获取服务查询策略，如果找到策略，则直接查询用户属性；p)执行BPEL-Assign指令设定策略获取服务请求信息，主要包括用户名name、访问资源resource等，然后执行BPEL-Invoke指令调用策略获取服务，接着执行BPEL-Pick...OnMessage指令任务根据服务配置选择数据库策略获取服务或者文件策略获取服务，最后从策略获取服务返回值中获取匹配此次访问请求的策略；q)执行BPEL-Assign指令设定属性缓存服务请求信息，然后执行BPEL-Invoke指令调用属性缓存服务返回当前缓存的属性，并根据查询结果执行BPEL-If指令任务，如果未找到属性，则调用属性获取服务查询属性，如果找到策略，则直接根据匹配策略和用户属性信息进行访问控制判定；r)执行BPEL-Assign指令设定属性获取服务请求信息，主要包括用户名name、访问资源resource等，然后执行BPEL-Invoke指令调用策略获取服务，接着执行BPEL-Pick...OnMessage指令任务根据服务配置和匹配策略选择数据库属性获取服务、LDAP属性获取服务或者感知器属性获取服务，最后从属性获取服务返回值中获取匹配此次访问请求的属性值；s)根据匹配策略和用户属性值进行访问控制判定，根据判定结果执行BPEL-Assign指令任务设定授权评估服务返回信息；审计处理过程负责解决用户访问记录、审计日志过滤等问题，它主要包括以下几个步骤：t)执行BPEL-Assign指令任务设定审计记录服务请求信息，主要包括但不仅限于：用户标识(用户名，假名ID)、认证域、访问资源标识、访问操作(添加、删除、浏览等)、访问结果、访问时间等；u)执行BPEL-Invoke指令异步调用审计记录服务，调用完成之后，需要一个BPEL-receive任务，来接受审计记录服务的返回值；v)通过BPEL-Assign指令设定安全访问响应信息，主要包括认证结果、访问控制结果、访问资源resource等，最后通过BPEL-Reply，将值返回给其调用者，完成整个安全业务访问流程；w)根据上述认证、访问控制、审计流程对相关服务进行集成得到身份认证服务、访问控制服务、审计服务，此时这些服务没有实际的功能实现，具体的功能实现通过信息安全共性构件来实现。

使用的流程说明：

使用的Web服务构件说明：

BPEL活动模块功能说明：

活动类型	任务功能
		<Invoke>	调用其他的web服务
<Receive>	等待客户发送的请求消息
		<Reply>	针对一个<Receive>活动生成同步响应
<Assign>	操作数据变量
		<Throw>	指示故障和异常
<Wait>	等待一段时间
		<Terminate>	终止整个流程
<Sequence>	定义一组按顺序调用的活动
		<Flow>	定义一组可以并行调用的活动

<Pick…OnMessage>	提供流程的入口
		<While>	用于定义循环执行逻辑

Claims (9)

1.一种基于BPEL的安全访问业务集成建模方法，其步骤包括：

1)从已有的应用业务中提取出安全访问业务，按照安全处理过程依次包括安全认证流程、授权与访问控制流程、审计与责任认定流程，并且通过集成的Web服务构件提供安全访问业务流程需要实现的功能；

2)安全访问业务通过BPEL-receive模块接收用户对于安全访问业务流程的调用请求，通过BPEL-Assign模块设定认证状态获取服务构件的输入参数变量，通过BPEL-Invoke模块，调用认证状态获取服务构件，查看用户的认证状态；

3)对经过认证的用户，通过BPEL-Assign模块设定认证断言服务构件的输入参数变量，然后通过BPEL-Invoke模块调用认证断言服务构件为认证结果生成一个断言，最后从认证断言服务构件的返回值中获取认证断言，结束认证处理流程；

4)通过BPEL-Assign模块设定授权评估服务构件的输入参数变量，通过BPEL-Invoke模块调用授权评估服务构件，用来评估可否对用户访问请求授权；

5)通过BPEL-Assign模块设定审计记录服务构件的输入参数变量，通过BPEL-Invoke模块异步调用审计记录服务构件；通过BPEL-receive模块，接受审计记录服务构件的返回值；

6)通过BPEL-Assign模块设定安全访问业务流程的输出参数变量，通过BPEL-Reply模块，将值返回给安全访问业务调用者，完成整个安全访问业务集成建模。

2.如权利要求1所述的方法，其特征在于，所述步骤3)对未经认证的先进行本地认证，其步骤包括：

2-1)通过BPEL-Invoke模块同步调用认证域选择服务，获取用户所属域；

2-2)通过BPEL-Assign模块设定用户所属域，通过BPEL-Invoke模块同步调用用户所属域上的认证服务；

2-3)认证服务通过BPEL-Pick...OnMessage模块根据用户选择的认证方式，通过BPEL-Invoke调用认证服务构件，并获取认证结果。

3.如权利要求2所述的方法，其特征在于，所述步骤2-1)获取用户所属域为外域，通过BPEL-Invoke调用身份联合服务获取用户假名。

4.如权利要求2所述的方法，其特征在于，所述认证服务构件包括：口令认证服务、证书认证服务、基于身份的认证服务和令牌认证服务。

5.如权利要求1所述的方法，其特征在于，所述步骤4)通过BPEL-Assign模块设定输入参数变量后，通过BPEL-While模块循环处理策略集中的策略，直到所有策略都处理完毕，具体包括：

4-1)通过BPEL-Invoke模块调用策略缓存服务，在缓存中检索所需要的策略；

4-2)如果检索到策略，通过BPEL-Invoke模块调用属性缓存服务，在缓存中检索所需要的属性；

4-3)如果检索到属性，根据策略和属性值信息进行访问控制判定，返回判定结果，访问控制处理流程结束。

6.如权利要求5所述的方法，其特征在于，所述步骤4-2)如果没有检索到策略，通过BPEL-Invoke模块调用策略获取服务，接着通过BPEL-Pick...OnMessage模块，根据系统配置选择策略获取服务，获取匹配的策略。

7.如权利要求5所述的方法，其特征在于，所述步骤4-3)如果没有检索到属性，通过BPEL-Invoke模块调用属性获取服务，接着通过BPEL-Pick...OnMessage模块，根据系统配置选择属性获取服务，获取匹配的属性值。

8.如权利要求6所述的方法，其特征在于，所述策略获取服务包括数据库策略获取服务或者文件略获取服务。

9.如权利要求7所述的方法，其特征在于，所述属性获取服务包括数据库属性获取服务、LDAP属性获取服务或者感知器属性获取服务。

Images