用于web服务的安全性策略验证

摘要

本发明公开了一种用于web服务的安全性策略验证的方法、设备和产品，包括：将用于web服务的安全性策略转换为策略谓词逻辑表示；提供表示安全性策略简档的一个或多个规则的简档谓词逻辑表示；以及根据策略谓词逻辑表示和简档谓词逻辑表示确定安全性策略是否满足安全性策略简档。

说明书

技术领域

本发明的领域涉及数据处理，或者，更具体地，涉及用于web服务的安全性策略验证的方法、设备和产品。

背景技术

许多企业当前都使用面向服务的体系结构(SOA)来进行开发，因为它们的商业模式变化得更加频繁了。SOA使得应用开发更加容易，因为独立于技术的服务可以在内联网上或者通过互联网耦接。由于商业模式变化得更加频繁，应用在其上运行的基础计算环境正变得更加复杂，因为计算机能够使用复杂的拓扑结构(包括防火墙和中间服务器)被连网。因此，非功能方面(例如安全性)的适当配置需要对这种复杂环境进行相当深入的理解。

根据这种开发，从一开始就将安全性与软件工程过程统一起来是重要的。遗憾地是，就安全性是在功能需求被实现以后再加上的意义而言，安全性通常被认为在大部分实际开发中是事后想到的。但是，众所周知，在设计过程的后期校正缺陷极大地增加了对这些缺陷的移除和修复的成本。

近来，服务组件体系结构(SCA)作为SOA的组件模型被标准化。针对非功能需求(例如安全性和事务处理)的意图在SCA的策略框架中的抽象水平上进行规定，并且这些意图被映射到具体的策略中，如WS-安全性策略。根据SCA策略框架，软件工程师应当预先准备WS-安全性策略文档的集合，以便从附属于SCA组件的安全性意图中检索策略。因此，重要的是从开发过程的一开始就为SCA组件定义有效的策略文档。

为了指导安全性策略的开发，大部分企业具有安全性简档(security profile)形式的安全性指南，该安全性简档描述了web服务安全性消息的格式。此外，也存在有关web服务安全性的标准简档，例如WS-I基本安全性简档，该简档也规定了行业标准安全性消息格式。然而，在现有技术中，确定安全性策略是否与安全性简档相符的过程是手动过程，由于SOA环境的复杂性而充满了错误。这样，读者将会理解在用于web服务的安全性策略验证方面存在着提升空间。

发明内容

本发明公开了用于web服务的安全性策略验证的方法、设备和产品，包括：将用于web服务的安全性策略转换为策略谓词逻辑表示(policy predicate logic representation)；提供表示安全性策略简档的一个或多个规则的简档谓词逻辑表示(profile predicate logicrepresentation)；并且根据策略谓词逻辑表示和简档谓词逻辑表示，确定安全性策略是否满足安全性策略简档。

附图说明

现在参考如下附图，将仅以示例的方式描述优选实施例，在附图中：

图1描绘了根据本发明实施例的能够进行用于web服务的安全性策略验证的示例性系统的功能性框图；

图2描绘了示出根据本发明实施例的用于web服务的安全性策略验证的示例性安全性策略和安全性简档的线条图；

图3描绘了示出根据本发明实施例的用于web服务的安全性策略验证的示例性方法的流程图；

图4描绘了示出根据本发明实施例的用于web服务的安全性策略验证的另一个示例性方法的流程图。

具体实施方式

从图1开始，参考附图描述根据本发明的实施例的用于web服务的安全性策略验证的示例性方法、设备和产品。图1描绘了根据本发明实施例的能够进行用于web服务的安全性策略验证的示例性系统的功能性框图。图1的示例性系统包括通过网络(100)连接在一起以便进行数据通信的几个计算装置(152、120、122、124)。在每个计算装置(152、120、122、124)上分别安装了web服务(108、110、112、114)。web服务是一种软件，设计用于支持通过网络的互操作的机器对机器的交互。web服务在网络上通过web应用编程接口(API)被频繁访问，并在作为所请求的web服务的主机的远程系统上执行。用于web服务的API通常利用web服务描述语言(WSDL)进行描述，并由服务代理根据通用描述、发现和集成(UDDI)协议发布。

在图1的示例性系统中，web服务通常根据SOAP通过基于可扩展标记语言(XML)的消息的交换进行通信。SOAP是用于通过计算机网络交换基于XML的消息的平台和独立于语言的协议，通常使用超文本传输协议(HTTP)或者安全HTTP。SOAP形成web服务堆栈的基础层，提供更抽象的层可以在其上建立的基本消息传送框架。在SOAP中有几种不同类型的消息传送模式，但是迄今为止，最常见的是远程过程调用(RPC)模式，其中一个web服务(客户机)发送请求消息到另一个web服务(服务器)，并且服务器马上发送响应消息到该客户机。以这样的方式，SOAP是XML-RPC的后继者，XML-RPC是使用XML来对其调用进行编码并使用HTTP作为传输机制的远程过程调用协议。

利用SOAP实现的web服务消息是普通XML文档，其包含如下单元：

·必需的封套(Envelope)单元，将XML文档标识为SOAP消息；

·可选的标题(Header)单元，包含标题信息；

·必需的主体(Body)单元，包括调用和响应信息；以及

·可选的故障(Fault)单元，提供有关当处理消息时发生的错误的信息。

为了确保SOAP消息交换的安全，web服务通常利用安全性令牌和其他安全性机制来保护web服务消息。用于嵌入安全性令牌和使用其他安全性特征来保护web服务消息的一种格式在由结构化信息标准促进组织(OASIS)发布的WS-安全性规范中描述。WS-安全性规范描述了如何将数字签名和加密标题加到SOAP消息上。此外，WS-安全性规范描述如何将安全性令牌(包括二进制安全性令牌，如X.509证书和Kerberos票据(ticket))附加到web服务消息。读者将注意到，执行安全性保护的web服务消息被称为“web服务安全性消息”。

在web服务安全性消息中，应用数据被嵌入到Body单元中，而安全性信息被嵌入到Header单元中。例如，考虑如下web服务安全性消息：

<soap:Envelope>

<soap:Header>

   <wsse:Security>

     <wsse:BinarySecurityToken 

        ValueType＝″X509v3″wsu:Id＝″X509Token″EncodingType＝″Base64Binary″>

        MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...

     </wsse:BinarySecurityToken>

                <ds:Signaturc>

                   <ds:Signedlnfo>

                      <ds:CanonicalizationMethod Algorithm＝″xml-exc-c14n″/>

                      <ds:SignatureMethod Algorithm＝″rsa-sha1″/>

        <ds:Reference URI＝″#body″>

                        <ds:Transforms>

                           <ds:Transform Algorithm＝″xml-exc-c14n″/>

                       </ds:Transforms>

                       <ds:DigestMethod Algorithm＝″sha1″/>

                       <ds:DigestValue>LyLsF094hPi4wPU...</ds:DigestValue>

     </ds:Reference>

                </ds:SignedInfo>

                <ds:SignatureValue>

                   Hp1ZkmFZ/2kQLXDJbchm5gK...

               </ds:SignatureValue>

               <ds:KeyInfo>

                  <wsse:SecurityTokenReference>

                  <wsse:Reference URI＝″#X509Token″/>

                  </wsse:SecurityTokenReference>

              </ds:KeyInfo>

           </ds:Signature>

        </wsse:Security>

    </soap:Header>

    <soap:Body wsu:Id＝″body″>

    <tru:StockSymbol xmlns:tru＝″http://fabrikam123.com/payloads″>

    QQQ

      </tru:StockSynbol>

  </soap:Body>

  </soap:Envelope>

上文的示例性web服务安全性消息示出了包含在由XML标签<soap:Body>和</soap:Body>规定的Body单元中的应用数据以及包含在由XML标签<soap:Header>和</soap:Header>规定的Header单元中的安全性数据。上述Header单元包括由XML标签<wsse:BinarySecurityToken>和</wsse:BinarySecurityToken>规定的二进制安全性令牌(BinarySecurityToken)单元中的X.059安全性令牌。上述Header单元还包括由XML标签<ds:Signature>和</ds:Signature>规定的签名(Signature)单元中的数字签名。Signature单元规定如下信息：

·Body单元被签名，

·签名算法，

·转换算法，

·对密钥的参考，

·摘要值，以及

·签名值。

为了创建和识别具有特定安全性特征的web服务消息，web服务利用例如存储在图1的计算装置(152)的RAM(168)中的web服务安全性策略(106)的安全性策略。web服务安全性策略定义了web服务使用或者产生的消息必须遵守的安全性规则。web服务安全性策略可以在根据国际商业机器公司等开发的WS-安全性策略规范的XML文档中进行规定。WS-安全性策略定义了若干部分，其可以包括在用于完整性和机密性声明、绑定和支持令牌的安全性策略中。完整性和机密性声明指出web服务消息的哪些特定部分应当分别被签名和加密。绑定规定了签名和加密消息的某些部分所需的详细信息，例如签名。绑定也规定了web服务消息中的加密算法、安全性令牌信息以及单元的布局。支持令牌是没有在绑定部分中描述的附加令牌。

例如考虑用于检验或产生上文描述的示例性web服务安全性消息的如下web服务安全性策略：

        …

        <sp:AsymmetricBinding>

           <sp:InitiatorToken id＝″initToken″>

              <sp:X509Token.../>

          </sp:InitiatorToken>

          <sp:RecipientToken id＝″recipToken″>

             <sp:X509Token.../>

         </sp:RecipientToken>

         <sp:AlgorithmSuite>

            <sp:Basic256/>

        </sp:AlgorithmSuite>

        <sp:Layout>

           <sp:Strict/>

       </sp:Layout>

   </sp:AsymmetricBinding>

   …

   <sp:SignedParts>

      <sp:Body/>

  </sp:SignedParts>

  …

上述示例性web服务安全性策略使用由XML标签<sp:SignedParts>和</sp:SignedParts>指示的“SignedParts(签名部分)”单元示出完整性声明。该“SignedParts”单元要求web服务安全性消息的Body单元被签名。上述示例性web服务安全性策略还使用由XML标签<sp:AsymmetricBinding>和</sp:AsymmetricBinding>指示的“AsymmetricBinding(非对称绑定)”部分示出绑定部分。该“AsymmetricBinding”部分规定web服务安全性消息的Header单元必须包括X.509证书，“Basic256”算法集用于签名和加密安全性消息，并规定使用“strict(严格)”布局来设置安全性消息中的单元。读者将注意到，为了清楚起见，上述示例性web服务安全性策略省略了逻辑操作符，例如，“all”或者“ExactlyOne”。在web服务安全性策略中有用的逻辑操作符可以包括在WS-安全性策略中规定的那些。

由于安全性策略可以用在各种不同的运行时环境中，计算装置(152)包括存储在RAM(168)中的运行时配置(107)。图1的运行时配置(107)规定了有关用于执行web服务安全性策略(106)的针对特定平台的环境的信息。例如考虑web服务安全性策略(106)规定使用用于签名和加密的特定X.509密钥。运行时配置(107)可以规定特定密钥文件和用于访问该密钥文件的ID/口令组合。

在图1的例子中，计算装置包括存储在RAM(168)中的安全性策略简档(103)。类似于安全性策略，安全性策略简档规定用于实现web服务间消息交换的安全性的规则或指南。如上所述，大部分企业具有安全性简档形式的安全性指南，以指导描述web服务安全性消息的格式的安全性策略的开发。例如，企业可以决定消息的Body单元将总是使用X.509密钥进行签名，并决定安全性消息中的单元以严格的方式进行设置。代替开发私有安全性简档，还存在用于web服务安全性的行业标准简档，例如WS-I基本安全性简档，该简档也规定了行业标准安全性消息格式。安全性策略简档的指南被用于开发web服务所使用的安全性策略，以识别web服务消息是否符合企业的安全性策略简档。

在图1的RAM(168)中还存储了策略验证模块(102)。图1的策略验证模块(102)是相对于安全性简档的规则确定安全性策略是否有效的计算机软件。图1的策略验证模块(102)包括根据本发明的实施例的一组计算机程序指令，用于web服务的安全性策略验证。如下文中将更详细地讨论的，根据本发明的实施例，图1的策略验证模块(102)通过如下步骤进行总体操作以便进行用于web服务的安全性策略验证：将用于web服务(108)的安全性策略(106)转换为策略谓词逻辑表示(101)；提供表示安全性策略简档(103)的一个或多个规则的简档谓词逻辑表示(104)；并且根据策略谓词逻辑表示(101)和简档谓词逻辑表示(104)确定安全性策略(106)是否满足安全性策略简档(103)。

除了相对于安全性简档的规则确定安全性策略是否有效以外，策略验证模块(102)还可以相对于策略在其中使用的运行时环境的运行时配置确定安全性策略是否有效。这种验证确保调用X.509密钥的安全性策略被部署在实际具有X.509密钥的环境中。这样，根据本发明的实施例，策略验证模块(102)也可以通过如下步骤进行总体操作以便进行用于web服务的安全性策略验证：提供表示运行时配置环境(107)的一个或多个配置参数的运行时配置谓词逻辑表示(105)；并且根据策略谓词逻辑表示(101)和运行时配置谓词逻辑表示(105)来确定安全性策略(106)是否匹配运行时配置环境(107)。

在RAM(168)中还存储了操作系统(154)。根据本发明实施例的用于将固件更新应用到数据中心中的服务器上的操作系统包括UNIX_TM、Linux_TM、MicrosoftXP_TM、AIX_TM、IBM的i5/OS_TM以及本领域技术人员能够想到的其他操作系统。图1的例子中的操作系统(154)、web服务(108)、web服务安全性策略(106)、安全性策略简档(103)、策略谓词逻辑表示(101)、简档谓词逻辑表示(104)、运行时配置(107)、运行时配置谓词逻辑表示(105)以及策略验证模块(102)被示出为在RAM(168)中，但许多这种软件组件通常也存储在非易失性存储器中，例如，盘驱动器(170)上。

图1的计算装置(152)包括通过扩展总线(160)和总线适配器(158)耦接到处理器(156)以及计算装置(152)的其他部件的盘驱动器适配器(172)。盘驱动器适配器(172)将非易失性数据存储器以盘驱动器(170)的形式连接到计算装置(152)。根据本发明实施例的在用于web服务的安全性策略验证的计算装置中有用的盘驱动器适配器包括集成驱动器电子部件(IDE)适配器、小型计算机系统接口(SCSI)适配器以及本领域技术人员能够想到的其他适配器。非易失性计算机存储器还可以实现为光盘驱动器、电子可擦除可编程只读存储器(EEPROM或者闪速存储器)(134)、RAM驱动器等，如本领域技术人员能够想到的。

图1的示例性计算装置(152)包括一个或多个输入/输出(I/O)适配器(178)。I/O适配器通过例如用于控制到例如计算机显示屏幕的显示装置的输出以及来自例如键盘和鼠标的用户输入装置(181)的用户输入的软件驱动器和计算机硬件，实现面向用户的输入/输出。图1的示例性计算装置(152)包括视频适配器(309)，该视频适配器是专门设计用于向例如显示屏幕或计算机监视器的显示装置(180)进行图形输出的I/O适配器的例子。视频适配器(309)通过高速视频总线(164)、总线适配器(158)以及也是高速总线的前端总线(162)连接到处理器(156)。

图1的示例性计算装置(152)包括耦接计算装置以便通过数据通信网络(100)与数据中心中的其他服务器进行数据通信的通信适配器(167)。这种数据通信网络(100)可以例如以例如通用串行总线(USB)的外部总线、或者因特网协议(IP)网络或者Ethernet_TM网络、I²C网络、系统管理总线(SM总线)、智能平台管理总线(IPMB)以及本领域技术人员能够想到的其他方式实现。通信适配器实现数据通信的硬件级，通过通信适配器，一个计算机直接或通过数据通信网络向另一个计算机发送数据通信。根据本发明实施例的对用于web服务的安全性策略验证有用的通信适配器的例子包括用于有线拨号通信的调制解调器、用于有线数据通信网络通信的以太网(IEEE802.3)适配器和用于无线数据通信网络通信的802.11适配器。

构成图1中示出的示例性系统的服务器和其他装置的设置用于解释，而非用于限制。根据本发明的各个实施例有用的数据处理系统可以包括图1中未示出的本领域技术人员能够想到的附加的服务器、路由器、其他装置和对等体系结构。在这种数据处理系统中的网络可以支持许多数据通信协议，包括例如TCP(传输控制协议)、IP(因特网协议)、HTTP(超文本传输协议)、WAP(无线接入协议)、HDTP(手持装置传输协议)以及本领域技术人员能够想到的其他协议。除了图1中示出的以外，本发明的各种实施例可以在各种硬件平台上实现。

为了进行进一步的解释，图2描绘了示出根据本发明实施例的用于web服务的安全性策略验证的示例性安全性策略和安全性简档的线条图。图2示出了安全性简档(200)，其描述了根据WS-I基本安全性简档(BSP)规范的web服务安全性消息的安全性特征，并示出了安全性简档(202)，其描述了根据组织自身的私有安全性指南的web服务安全性消息的安全性特征。图2还描述了三个安全性策略(204、206、208)，其规定web服务产生或者使用的安全性消息的安全性特征。图2的安全性策略(204、206、208)可以根据例如WS-安全性策略规范来执行。

在图2的例子中，安全性简档(200、202)和安全性策略(204、206、208)被转换为谓词逻辑表示(210)。安全性策略的谓词逻辑表示规定安全性策略和web服务消息之间的关系，也就是说，web服务消息是否符合特定安全性策略。类似地，安全性简档的谓词逻辑表示规定安全性简档和web服务消息之间的关系，也就是说，web服务消息是否与特定安全性简档相符。以这种方式，图2的谓词逻辑表示(210)将安全性简档(200、202)和安全性策略(204、206、208)映射到web服务消息的全域(212)。WS-I BSP安全性简档(200)的谓词逻辑表示规定消息全域(212)的子集“A”中的所有消息与WS-IBSP安全性简档(200)相符。组织的私有安全性简档(202)的谓词逻辑表示规定消息全域(212)的子集“B”中的所有消息与组织的私有安全性简档(202)相符。安全性策略1(204)的谓词逻辑表示规定消息全域(212)的子集“C”中的所有消息与安全性策略1(204)相符。安全性策略2(206)的谓词逻辑表示规定消息全域(212)的子集“D”中的所有消息与安全性策略2(206)相符。安全性策略3(208)的谓词逻辑表示规定消息全域(212)的子集“E”中的所有消息与安全性策略3(208)相符。

如上所述，软件开发者使用组织自身的私有安全性简档或者例如WS-I BSP的行业标准安全性简档的指南来开发web服务使用的安全性策略。如图2中所示，策略验证模块可以通过确定是否存在满足策略谓词逻辑表示以及不满足简档谓词逻辑表示的web服务消息，根据策略的谓词逻辑表示和简档的谓词逻辑表示来确定安全性策略是否满足安全性策略简档。例如，相对于WS-I BSP安全性简档(200)和组织自身的私有安全性简档(202)考虑安全性策略1、2和3(204、206、208)是否有效。图2示出了安全性策略1(204)和安全性策略2(206)满足WS-I BSP安全性简档(200)，因为消息子集“C”和“D”都在消息子集“A”中。图2示出了安全性策略3(208)不满足WS-I BSP安全性简档200，因为消息子集“E”不在消息子集“A”中。图2示出了安全性策略1(204)满足组织自身的私有安全性简档(202)，因为消息子集“C”在消息子集“B”中。图2示出了安全性策略2(206)和安全性策略3(208)不满足组织自身的私有安全性简档(202)，因为消息子集“D”和消息子集“E”都不在消息子集“B”中。

如上所述，安全性简档(200、202)和安全性策略(204、206、208)在图2的例子中被表示为谓词逻辑表示(210)。谓词逻辑表示(210)可以利用Prolog来实现。Prolog是基于谓词逻辑的高级编程语言。不像基于执行命令序列的传统编程语言，Prolog基于定义并且然后求解逻辑公式。Prolog有时被称为说明性语言或者基于规则的语言，因为其程序包括事实和规则的列表。包括Prolog程序的事实和规则通常存储在称为Prolog数据库的程序文件中。包括事实声明和逻辑规则的Prolog数据库被正确地视为知识库或者规则库。在本公开内容中，Prolog的使用是示例性的，并不是本发明实施例中的要求。除了Prolog以外，许多方法和装置，以及许多计算机语言都将被本领域技术人员想到用于建立规则库，并且所有这些方法、装置和语言都在本发明的范围内。

在Prolog中的事实和规则通常都以谓词逻辑形式设置。例如，下文是示例性的一组三个Prolog子句：

parent(fred，greta).

parent(greta，henry).

grandparent(X，Z)：-parent(X，Y)，parent(Y，Z)

Prolog子句通常有三种类型：事实(Fact)说明真的事件。规则(Rule)说明取决于给定条件为真的事件。当规则被称为“真”时，问题(Question)被用于查明声明的事实当前是否满足特定规则。Prolog问题有时被称为“目标”或“询问”。在上文中三行的例子中，“parent(fred，greta)”是事实。“Parent”是谓词。“Fred”是第一自变量，有时称为“主体”。“Greta”是第二自变量，有时称为“客体”。

在上文三行的例子中，“grandparent(X，Z)：-parent(X，Y)，parent(X，Y).”是规则。“Grandparent(X，Z)”被称为规则的“头”。“Parent(X，Y)，Parent(Y，Z)”被称为规则的“主体”。“Parent(X，Y)”是规则的第一子目标。“Parent(Y，Z)”是规则的第二子目标。X、Y和Z是变量。

该示例性规则以几种方法被正确描述。一种说明性描述是：对所有的X和Z，如果存在某一Y使得X是Y的父母并且Y是Z的父母，那么X是Z的祖父母。另一个说明性描述是：对于所有的X，Y和Z，如果X是Y的父母，Y是Z的父母，那么X是Z的祖父母。规则的程序性解释是：如果首先，目标parent(X，Y)成功地绑定X1和Y1，并且然后目标parent(Y，Z)成功绑定Y1和Z1，那么目标grandparent(X，Z)成功为X绑定X1并为Z绑定Z1。

如果Prolog目标能够从Prolog数据库中的一组子句中被满足，那么它被称为是“成功的”。如果目标不能被这样满足，那么目标失败。对于基于上述的一组三行示例性Prolog子句的例子：由于X被实例化为henry，询问“grandparent(fred，X)”被满足。另一方面，询问“grandparent(fred，bob)”不能从三行的示例性Prolog数据库中被满足，因为“bob”没有出现在该组子句中。

为了进一步说明，图3描绘了示出根据本发明实施例的用于web服务的安全性策略验证的示例性方法的流程图。图3的方法包括将用于web服务的安全性策略(106)转换(300)为策略谓词逻辑表示(101)。图3的安全性策略(106)示出了web服务使用或产生的消息必须遵守的一组安全性规则。图3的策略谓词逻辑表示(101)规定了安全性策略(106)和web服务消息之间的关系，也就是说，web服务消息是否符合安全性策略(106)。例如，考虑在上文描述过的示例性安全性策略的如下策略谓词逻辑表示：

01：myPolicy(E)：-

02：  E＝env(H，B)，

03：  H＝h(Sec)，

04：  Sec＝

05：  sec(

06：     bst(′@ValueType′(′#X509v3′)，

07：     ′@EncodingType′(′#Base64Binary′)，

08：     ′@id′(TokenID)，

09：     bstValue)，

10：     sig(

11：     sigInfo(

12：     c14nMethod(′@Algorithm′(′xml-exc-c14n#′))，

13：     sigMethod(′@Algorithm′(′xmldsig#rsa-sha1′))，

14：     ref(′@URL′(BodyID)，

15：           transforms(

16：               transform(

17：               ′@Algorithm′(′xml-exc-c14n#′))，

18：               digestMethod(′@Algorithm′(′xmldsig#sha 1′))，

19：               digestValue(dVal)))，

20：        sigValue(sVal)，

21：        keyInfo(

22：           str(reference(′@URI′(TokenID)))))))，

23：    B＝body(′@id′(BodyID)，bodyValue).

在01-23行中的上述Prolog规则用于实现上述参考图1的示例性安全性策略的策略谓词逻辑表示。在01行中的“myPolicy(E)”用作Prolog规则的头，并且02-23行中的所有内容用作Prolog规则的主体。在01行中的变量“E”表示web服务消息。上述Prolog规则规定符合Prolog规则的主体中的目标的所有web服务消息也符合安全性策略“myPolicy”。也就是说，如果上述Prolog规则的02-23行中的每个目标对于特定web服务消息为真，那么web服务消息符合安全性策略“myPolicy”也为真。

通过根据基本规则(primitive rule)、结构规则和合并规则，将用于web服务的安全性策略(106)转换为策略谓词逻辑表示(101)，可以执行根据图3的方法的将用于web服务的安全性策略(106)转换(300)为策略谓词逻辑表示(101)。基本规则是提供用于将安全性策略的片断转换为策略谓词逻辑表示的片断的指令的转换规则。例如，基本规则可以提供指令，用于将如下安全性策略片断

 <sp:SignedParts>

     <sp:Body/>

 </sp:SignedParts>

 转换为策略谓词逻辑表示的如下片断：

  sig(

  sigInfo(

  c14nMethod(@Algorithm($[c14n])，

  sigMethod(@Algorithm($[sigMethod]))，

  ref(@URL(BodyID)，

           transforms(

               transform(@Algorithm($[transform]))，

         digestMethod(@Algorithm($[digest]))，

         digestValue(***)))，

  sigValue(***)，

  keyInfo(

            str(Reference(@URI(***)))))

  并转换为策略谓词逻辑表示的如下附加片断：

  body(@id(BodyID))

在上述例子中，由于安全性策略片断中的“SignedParts”单元要求消息中的签名单元，上述“sig”策略谓词逻辑表示片断也规定消息要求签名单元。此外，由于安全性策略片断中的“SignedParts”单元规定消息的Body被签名，上述“主体”策略谓词逻辑表示片断规定消息要求Body单元。

对于另一个例子，基本规则可以提供指令，用于将如下安全性策略片断

 <sp:EncryptedParts>

     <sp:Body/>

 </sp:EncryptedParts>

转换为策略谓词逻辑表示的如下片断：

encKey(

       encMethod(@Algorithm(***))，

       keyInfo(str(Reference(@URI(***))))，

       cipherData(cipherValue(***)，

       refList(dataRef(@URI(enc1))))

并转换为策略谓词逻辑表示的如下附加片断：

encData(@Type(...#Element)，@Id(enc1))，

        encMethod(@Algorithm(***))，

        cipherData(cipherValue(***)))

在上述例子中，由于安全性策略片断中的“EncryptedParts”单元要求消息的Body单元被加密，上述“encKey”和“encData”策略谓词逻辑表示片断规定在web服务消息中被要求的加密密钥信息和加密数据信息。

对另一个例子，基本规则可以提供指令，用于将如下安全性策略片断

<sp:X509Token sp:IncludeToken＝″AlwaysToRecipt″>

<sp:WssX509V3Token10/>

</sp:X509Token>

转换为策略谓词逻辑表示的如下片断：

bst(@ValueType(...#X509v3)，@EncodingType(...#Base64Binary)，

    @id(X509Token)，BstVal)

在上述例子中，基本规则用于将要求消息的签名部分的X.509安全性令牌的安全性策略片断转换为规定消息应当具有X.509二进制签名令牌(bst)的“bst”策略谓词逻辑表示片断。

对于另一个例子，基本规则可以提供指令，用于将如下安全性策略片断：

<sp:UsernameToken sp:IncludeToken＝″AlwaysToRecipt″>

<sp:WssUsernameToken10/>

</sp:UsernameToken>

转换为策略谓词逻辑表示的如下片断：

usernametoken(

          un(ID)，

          pwd(PWD))

在上述例子中，基本规则用于将要求消息的签名部分的用户名安全性令牌的安全性策略片断转换为规定消息应当具有用户名/口令组合的“用户名令牌(usernametoken)”策略谓词逻辑表示片断。

对于另一个例子，基本规则可以提供指令，用于将如下安全性策略片断

<sp:MustSupportRefKeyIdentifier/>

转换为策略谓词逻辑表示的如下片断：

keyID(@EncordingType(***)，@ValueType(***)，keyIdentifier).

在上述例子中，基本规则用于将要求web服务消息以支持参考令牌识别符的安全性策略片断转换为规定消息应当规定参考密钥识别符的“密钥ID(keyID)”策略谓词逻辑表示片断。

对于另一个例子，基本规则可以提供指令，用于将如下安全性策略片断

<sp:MustSupportRefIasuerSerial/>

转换为策略谓词逻辑表示的如下片断：

STR(

      X509IssuerSerial(

         X509IssuerName(DName)，

         X509SerialNumber(sNumber))).

在上述例子中，基本规则用于将要求web服务消息以支持对令牌发布者的参考的安全性策略片断转换为规定消息应当规定X.509发布者的“STR”策略谓词逻辑表示片断。

对于另一个例子，基本规则可以提供指令，用于将如下安全性策略片断

<sp:MustSupportRefEmbeddedToken/>

转换为策略谓词逻辑表示的如下片断：

STR(

        Embedded(@id(***)，***)).

在上述例子中，基本规则用于将要求web服务消息以支持对嵌入令牌的参考的安全性策略片断转换为规定消息应当规定嵌入的安全性令牌的标识符的“STR”策略谓词逻辑表示片断。读者将注意到，基本规则从安全性策略片断产生的上述策略谓词逻辑表示片断是Prolog规则的片断。上述Prolog规则片断被示出用于解释而不是限制。基本规则可以用于将安全性策略片断转换为本领域技术人员将想到的策略谓词逻辑表示片断的其他形式。

结构规则是将安全性策略(106)的消息单元结构要求表达为策略谓词逻辑表示(101)的转换规则。例如，安全性策略中的“布局(Layout)”单元定义了SOAP消息标题中的单元顺序，并且安全性策略中的“EncryptBeforeSigning”单元要求加密必须在签名之前被执行。

合并规则是定义如何将由基本规则创建的策略谓词逻辑表示片断合并成单个策略谓词逻辑表示的转换规则。只使用基本规则和结构规则，构建的策略谓词逻辑表示可能具有冗余单元或者可能缺乏单元之间的必要关联。例如，考虑web服务安全性策略的如下部分：

<sp:AsymmctricBinding>

        <sp:InitiatorToken>

           <sp:X509Token sp:IncludeToken＝″AlwaysToRecpt″>

              <sp:WssX509V3Token 10/>

           </sp:X509Token>

       </sp:InitiatorToken>

       <sp:AlgorithmSuite>

          <sp:Basic256/>

       </sp:AlgorithmSuite>

</sp:AsymmetricBinding>

<sp:SignedParts>

          <sp:Body/>

</sp:SignedParts>

以及其对应的策略谓词逻辑表示的如下部分：

 bst(@ValueType(...#X509v3)，

           @EncodingType(...#Base64Binary)，

           @id(X509Token)，BstVal)，

 … 

 sig(

         sigInfo(

         c14nMethod(@Algorithm(.../xml-exc-c14n#))，

         sigMethod(@Algorithm(.../xmldsig#rsa-sha1))，

         ref(@URL(BodyID)，

             transforms(

                 transform(@Algorithm(.../xml-exc-c14n#)))，

                 digestMethod(@Algorithm(.../xmldsig#sha1))，

                 digestValue(dVal)))

          sigValuc(sVal)，

          keyInfo(str(Referenee(@URI(#X509Token)))))

…

body(@id(BodyID))

利用基本规则，“X509Token”单元和“SignedParts”单元被分别转换为“bst”单元和“sig”单元。在应用合并规则时，读者将注意到在安全性策略中的“AlgorithmSuite”单元下的“Basic256”标识符用于规定签名的算法。这样，上述例子中的合并规则通过应用“SignedParts”单元创建的签名单元必须参考“InitiatorToken”单元中规定的令牌的规则，将X.509令牌与“sig”单元相关联。

图3的方法还包括提供(304)表示安全性策略简档(103)的一个或多个规则的简档谓词逻辑表示(104)。图3的安全性策略简档(103)规定用于实现web服务间消息交换中的安全性的规则或者指南。可以利用组织自身的私有安全性指南集、安全性指南的行业标准集(如WS-I基本安全性简档规范)，或者本领域技术人员将想到的任何其他实现方式，实现安全性策略简档(103)。图3的简档谓词逻辑表示(104)规定安全性简档(103)和web服务消息之间的关系，也就是说，web服务消息是否与安全性简档(103)相符。为了进一步解释，考虑有关根据WS-I基本安全性简档规范实现的安全性简档中的安全性令牌子站(substation)的如下指南：

C5443：当签名者的SECURITY_TOKEN是INTERNAL_SECURITY_TOKEN时，SIGNED_INFOR可以包括SIG_REFERENCE，其参考签名者的SECURITY_TOKEN，以防止用使用相同密钥的另一个SECURITY_TOKEN进行替代。

软件开发者可以提供上述示例性安全性简档规则的如下简档谓词逻辑表示：

01：c5443(E)：-

02：   …

03：   sec(

04：      sig(...

05：          ref(′@URL′(BodyID)，...)

06：          ref(′@URL′(TokenID)，...)

07：          ...)，

08：    B＝body(′@id′(BodyID)，bodyValue).

01-08行中的上述示例性安全性简档规则被实现为Prolog规则。01行中的“c5443(E)”用作Prolog规则的头，并且02-08行中的所有内容用作Prolog规则的主体。上述Prolog规则规定与Prolog规则的主体中的目标相符的所有web服务消息(即，签名包括参考签名者安全性令牌的签名参考)，也与安全性简档规则“c5443”相符。也就是说，如果上述Prolog规则的02-08行中的每个目标对于特定web服务消息为真，那么该web服务消息与安全性简档规则“c5443”相符为真。

图3的方法还包括根据策略谓词逻辑表示(101)和简档谓词逻辑表示(104)确定(306)安全性策略(106)是否满足安全性策略简档(103)。通过确定是否存在满足策略谓词逻辑表示(101)并且不满足简档谓词逻辑表示(104)的web服务消息，可以执行根据图3的方法确定(306)安全性策略(106)是否满足安全性策略简档(103)。通过利用策略谓词逻辑表示(101)和简档谓词逻辑表示(104)执行Prolog表达式，可以执行确定是否存在满足策略谓词逻辑表示(101)并且不满足简档谓词逻辑表示(104)的web服务消息。例如，考虑示例性策略谓词逻辑表示“myPolicy”和示例性简档谓词逻辑表示“c5443”。利用这些示例性表示，执行如下Prolog表达式评估为真或假：

myPolicy(E)，～c5443(E)

如果存在不满足“c5443”安全性简档规则但的确满足“myPolicy”安全性策略的web服务消息“E”，那么上述示例性Prolog表达式评估为真。如果不存在不满足“c5443”安全性简档规则但的确满足“myPolicy”安全性策略的web服务消息“E”，那么上述示例性Prolog表达式评估为假。因此，如果表达式“myPolicy(E)，～c5443(E)”评估为假，那么安全性策略(106)满足安全性策略简档(103)。然而，如果表达式“myPolicy(E)，～c5443(E)”评估为真，安全性策略(106)不满足安全性策略简档(103)。如下文中将更详细地讨论的，当安全性策略(106)不满足安全性策略简档(103)时，Prolog可以提供满足表达式“myPolicy(E)，～c5443(E)”的web服务消息的例子，从而给策略开发者提供示例性消息，该消息表明安全性策略(106)不满足安全性策略简档(103)。策略开发者可以利用这种示例性消息来识别为什么安全性策略(106)不满足安全性策略简档(103)。从上述讨论中，读者可以注意到，在安全性策略(106)和安全性简档(103)以谓词逻辑表示被表示后，那么可以仅仅通过利用该表示评估谓词逻辑表达式来执行确定(306)安全性策略(106)是否满足安全性策略简档(103)。

图3的方法还包括如果安全性策略(106)满足安全性策略简档(103)，通知(308)用户安全性策略有效。根据图3的方法通知(308)用户安全性策略有效可以通过在图形用户界面(GUI)上向用户呈现安全性策略(106)与安全性策略简档(103)相符的通知来执行。

图3的方法还包括如果安全性策略(106)不满足安全性策略简档(103)，则通知(310)用户安全性策略(106)与安全性策略简档(103)的至少一个规则不相符。根据图3的方法通知(310)用户安全性策略(106)与安全性策略简档(103)的至少一个规则不相符可以通过在GUI上向用户呈现安全性策略(106)与安全性策略简档(103)不相符的通知来执行。根据图3的方法通知(310)用户安全性策略(106)与安全性策略简档(103)的至少一个规则不相符还可以通过向用户提供消息的例子表明安全性策略(106)不满足安全性策略简档(103)来执行。例如，再次考虑上述示例性Prolog表达式：

myPolicy(E)，～c5443(E)

如果上述Prolog表达式评估为真，那么Prolog返回满足该表达式的web服务消息“E”的实例。也就是，Prolog返回不满足“c5443”安全性简档规则但的确满足“myPolicy”安全性策略的示例性消息。表明安全性策略(106)不满足安全性策略简档(103)的消息的这种例子对于软件开发者修改安全性策略(106)以与安全性策略简档(103)相符是有用的。

参考图3的上述解释描述了相对于安全性简档的规则的、根据本发明实施例的用于web服务的安全性策略验证。如上所述，根据本发明实施例的用于web服务的安全性策略验证也可以相对于其中利用策略的运行时环境的运行时配置来执行。例如，这种验证确保调用X.509密钥的安全性策略被部署在实际上具有X.509密钥的环境中。为了进一步解释，图4描绘了示出根据本发明实施例的用于web服务的安全性策略验证的另一个示例性方法的流程图。图4的方法包括将用于web服务的安全性策略(106)转换(300)为策略谓词逻辑表示(101)。以类似于上面参考图3描述的方式的方式，执行根据图4的方法的将用于web服务的安全性策略(106)转换(300)成为策略谓词逻辑表示(101)。

图4的方法还包括提供(400)表示运行时配置环境(107)的一个或多个配置参数的运行时配置谓词逻辑表示(105)。图4的运行时配置环境(107)规定有关用于执行特定web服务的针对特定平台的环境的信息。图4的运行时配置谓词逻辑表示(105)规定运行时配置环境(107)与web服务消息之间的关系，也就是，运行时配置环境是否支持web服条消息。例如，考虑特定运行时配置环境的如下运行时配置谓词逻辑表示：

01：RTEnvironment(E)：-

02：  E＝env(H，B)，

03：  H＝h(Sec)，

04：     Sec＝sec(...)

05： B＝body(...).

01-05行中的上述示例性运行时配置谓词逻辑表示被实现为Prolog规则。01行中的“RTEnvironment(E)”用作Prolog规则的头，02-05行中的所有内容用作Prolog规则的主体。上述Prolog规则描述特定运行时配置环境支持的所有web服务消息“E”。也就是说，对于特定运行时配置环境支持的所有消息，规则“RTEnviroment(E)”为真，并且对于特定运行时配置环境不支持的所有消息，规则“RTEnviroment(E)”为假。

图4的方法包括根据策略谓词逻辑表示(101)和运行时配置谓词逻辑表示(105)，确定(404)安全性策略(106)与运行时配置环境(107)是否匹配。通过确定是否存在运行时配置环境(107)不支持但是的确满足安全性策略(106)的消息，可以执行根据图4的方法的确定(404)安全性策略(106)与运行时配置环境(107)是否匹配。通过使用策略谓词逻辑表示(101)和运行时配置谓词逻辑表示(105)执行Prolog表达式，可以执行确定是否存在运行时配置环境(107)不支持但的确满足安全性策略(106)的消息。例如，考虑示例性策略谓词逻辑表示“myPolicy”和示例性运行时配置谓词逻辑表示“RTEnvironment”。利用这些示例性表示，执行如下Prolog表达式评估为真或假：

myPolicy(E)，～RTEnvironment(E)

如果存在“RTEnvironment”所表示的运行时环境不支持但的确满足“myPolicy”安全性策略的web服务消息“E”，则上述示例性Prolog表达式评估为真。如果不存在“RTEnvironment”所表示的运行时环境不支持但的确满足“myPolicy”安全性策略的web服务消息“E”，则上述示例性Prolog表达式评估为假。因此，如果Prolog表达式“myPolicy(E)，～RTEnvironment(E)”评估为假，那么安全性策略(106)与运行时配置环境(107)匹配。然而，如果Prolog表达式“myPolicy(E)，～RTEnvironment(E)”评估为真，那么安全性策略(106)与运行时配置环境(107)不匹配。读者将注意到，在安全性策略(106)和运行时配置环境(107)以谓词逻辑表示被表示之后，则可以仅仅通过利用该表示评估谓词逻辑表达式来执行确定(404)安全性策略(106)是否与运行时配置环境(107)匹配。

图4的方法包括如果安全性策略(106)与运行时配置环境(107)匹配，则通知(406)用户安全性策略(106)与运行时配置环境(107)相符。通过在图形用户界面(GUI)上向用户呈现安全性策略(106)与运行时配置环境(107)相符的通知，可以执行根据图4的方法的通知(406)用户安全性策略(106)与运行时配置环境(107)相符。

如果安全性策略(106)与运行时配置环境(107)不匹配，图4的方法通知(408)用户安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符。通过在GUI上向用户呈现安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符的通知，可以执行根据图4的方法的通知(408)用户安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符。也可以通过向用户提供表明安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符的消息的例子，来执行根据图4的方法的通知(408)用户安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符。例如，再次考虑上述示例性Prolog表达式：

myPolicy(E)，～RTEnvironment(E)

如果上述Prolog表达式评估为真，那么Prolog返回满足该表达式的web服务消息的实例。也就是说，Prolog返回“RTEnvironment”所表示的运行时环境不支持但的确满足“myPolicy”安全性策略的示例性消息。表明安全性策略(106)与运行时配置环境(107)的至少一个配置参数不相符的这种消息的例子对于软件开发者修改安全性策略(106)或者运行时配置环境(107)可能是有用的。

本发明的示例性实施例主要是在用于web服务的安全性策略验证的全功能计算机系统的上下文中描述的。但是，本领域技术人员将认识到，本发明的实施例也可以在置于用于任何适当的数据处理系统的计算机可读介质上的计算机程序产品中实现。这种计算机可读介质可以是传输介质或者用于机器可读信息的可记录介质，包括磁性介质、光学介质或者其他适当的介质。可记录介质的例子包括硬盘驱动器中的磁盘或者软盘、用于光学驱动器的压缩盘、磁带以及本领域技术人员将想到的其他介质。传输介质的例子包括用于语音通信的电话网络以及数字数据通信网络(例如Ethernets_TM和利用因特网协议及万维网通信的网络以及无线传输介质，例如根据IEEE802.11规范族实现的网络)。本领域技术人员很容易认识到任何具有适当的编程装置的计算机系统将能够执行在程序产品中实现的本发明的方法的步骤。本领域技术人员将很容易认识到，尽管本说明书中描述的一些示例性实施例指向了安装在计算机硬件上并在其上执行的软件，但是，实现为固件或硬件的可选实施例在本发明的范围内。本说明书的描述仅仅意在说明而非在限制的意义上进行解释。