Web 服务寻址 (WS-Addressing)

  • 项目

由Adam Bosworth,BEA, Don Box，Microsoft（编辑）, Erik Christensen，Microsoft, Francisco Curbera，IBM（编辑）, Donald Ferguson，IBM, Jeffrey Frey，IBM, Chris Kaler，Microsoft, David Langworthy，Microsoft, Frank Leymann，IBM, Steve Lucco，Microsoft, Steve Millet，Microsoft, Nirmal Mukhi，IBM, Mark Nottingham，BEA, John Shewchuk，Microsoft, Tony Storey，IBM, Sanjiva Weerawarana，IBM

版权声明

版权所有 2002-2003，BEA Systems Inc.，International Business Machines Corporation，Microsoft Corporation。保留所有权利。

谨此授权用户以任何介质复制和显示 WS-Addressing 规范而无须缴纳任何费用或许可证使用费，前提是用户在其所制作的 WS-Addressing 规范（或该规范的某些部分）的所有副本中包含以下信息：

  • 1.指向 WS-Addressing 规范所在位置的链接或 URL

  • 2.WS-Addressing 规范中所示的版权声明。

BEA Systems、IBM 和 Microsoft（合称“作者”）同意在合理的商业条款与条件下，就其认为实现 WS-Addressing 规范所必需的各自的专利向用户授予免收版税的许可证。

WS-Addressing 规范是“按现状”提供的，并且作者不做任何明示或暗示的表示与保证，包括（但不限于）适销性保证、适用于特定用途、非侵权性或所有权；不以任何方式表示或保证 WS-Addressing 规范的内容适用于任何用途；也不以任何方式表示或保证对这些内容的实现不会侵犯任何第三方专利权、版权、商标或其他权利。

作者将不对任何使用或分发 WS-Addressing 规范造成的或与此有关的任何直接的、间接的、特殊的、意外的或有连带关系的损害负责。

未经事先明确的书面许可，不得以任何方式（包括与 WS-Addressing 规范或其内容相关的广告或宣传）使用作者的名称和商标。 作者始终拥有 WS-Addressing 规范中版权的所有权。

并不以暗示、禁止或其他方式授予任何其他权利。

摘要

WS-Addressing 提供了多种与传输无关的机制对 Web 服务和消息进行寻址。 具体来说，此规范定义 XML 元素以标识 Web 服务终结点，并保护消息中的端到端终结点标识。 此规范允许消息处理系统支持通过网络（包含处理节点）以一种与传输无关的方式进行消息处理，而这些处理节点可以是终结点管理器、防火墙和网关。

状态

WS-Addressing 及相关的规范是“按现状”提供的，并仅供查看和评估用。 BEA、IBM 和 Microsoft 都希望在不久的将来能够收到您的投稿并征求到您的建议。 BEA、IBM 和 Microsoft Corporation 不以任何方式就这些规范做出任何保证或陈述。

*

本页内容
  1. 简介
  2. 终结点引用
  3. 消息信息标头
  4. 安全性注意事项
  5. 致谢
  6. 参考资料

1. 简介

Web 服务寻址 (WS-Addressing) 定义了两种结构，它们传达的信息一般由传输协议和消息处理系统以一种可互操作的方式提供。 这些结构将该底层信息规格化为一种统一的格式，而对这种格式的处理可以独立于传输或应用程序。 这两种结构就是终结点引用 和消息信息标头。

Web 服务终结点是一个（可引用的）实体、处理器或可以作为 Web 服务消息目标的资源。 终结点引用传达了标识／引用一个 Web 服务终结点所需的信息，它的使用方式可以有多种： 终结点引用适用于传达访问 Web 服务终结点所需的信息，但也可为在 Web 服务间往返的各条消息提供地址。 为了处理上一种使用情况，本规范定义了一系列消息信息标头，以允许对与底层传输无关的消息进行统一寻址。 这些消息信息标头传递端到端的消息特性，包括对源终结点和目标终结点以及消息标识进行寻址。

由于这两种结构都设计为可扩展且可重用，因此人们可以充分利用终结点引用和消息信息标头并构建其他规范。

下面的示例阐明了如何利用这些机制将一条 SOAP 1.2 消息从 http://business456.com/client1 发送到 http://fabrikam123.com/Purchasing：

(001) <S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"
         xmlns:wsa="https://schemas.xmlsoap.org/ws/2003/03/addressing">
(002)   <S:Header>
(003)     <wsa:ReplyTo>
(004)       <wsa:Address>http://business456.com/client1</wsa:Address>
(005)     </wsa:ReplyTo>
(006)     <wsa:To>http://fabrikam123.com/Purchasing</wsa:To>
(007)     <wsa:Action>http://fabrikam123.com/SubmitPO</wsa:Action>
(008)   </S:Header>
(009)   <S:Body>
(010)     ...
(011)   </S:Body>
(012) </S:Envelope>

行 (002) 到 (008) 表示 SOAP 消息的标头，可以在其中使用规范中所定义的机制。 行 (009) 到 (011) 表示消息的主体。

行 (003) 到 (007) 包含消息信息标头块。 具体说来就是，行 (003) 到 (005) 指定一个终结点，这条消息的应答应该作为一个终结点引用发送到该终结点。 行 (006) 指定这条消息的最终接收方的地址 URI。 行 (007) 指定一个用于标识期望语义的 Action URI。

1.1. 词语约定

本文中的关键字“必须（MUST）”、“绝不可以（MUST NOT）”、“需要的（REQUIRED）”、“将（SHALL）”、“将不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐的（RECOMMENDED）”、“可以（MAY）”和“可选的（OPTIONAL）”将按 RFC 2119 2 中的说明来解释。

在描述抽象数据模型时，本规范使用在 XML 信息集 [7] 中所用的词语约定。 具体来说，抽象属性名称总是出现在方括号中（例如，[some property]）。

在说明具体的 XML 架构时，本规范使用 WS-Security [15] 中的词语约定。 具体来说，利用一个类似 XPath 的符号表示法（例如，/x:MyHeader/x:SomeProperty/@value1）来说明一个元素的 [children] 或 [attributes] 属性的每个成员。 使用 {any} 则表示存在一个元素通配符（<xs:any/>）。 而使用 @{any} 则表示存在一个属性通配符（<xs:anyAttribute/>）。

1.2. 命名空间

整篇规范使用了许多命名空间前缀；这些前缀都列在表 1 中。 请注意，任何命名空间前缀的选择都是任意的并且对语义的影响也不大（请参阅 [6]）。

前缀

命名空间

S

http://www.w3.org/2002/12/soap-envelope

wsa

https://schemas.xmlsoap.org/ws/2003/03/addressing

wsp

https://schemas.xmlsoap.org/ws/2002/12/policy

xs

http://www.w3.org/2001/XMLSchema

表 1 本规范中使用的前缀和命名空间

WS-Addressing 是根据 XML 信息集 [7] 定义的。 WS-Addressing 符合 SOAP 1.2 [11][12] 处理模型；但在使用本规范中定义的结构时 SOAP 1.2 并不是必需的。 WS-Addressing 也设计为能够用于 WSDL 1.1 [13] 所描述的各项服务。 本规范中的示例使用了 XML 1.0 [5] 表示，但这并不是必需的。

WS-Addressing 定义的所有信息项都是由 XML 命名空间 URI [6] "https://schemas.xmlsoap.org/ws/2003/03/addressing" 标识的。 通过解除对 XML 命名空间 URI 的引用即可获得一个标准化的 XML 架构 [8][9] 文档。

2. 终结点引用

本节定义了终结点引用的模型和语法。

本规范引入“终结点引用”这个新的描述元素类型是为了支持目前在 WSDL 1.1 [13] 中尚未适当包含的一组动态使用模式。 具体来说，本规范旨在推动下列使用方案：

  • 动态生成并自定义服务终结点说明。

  • 标识并说明由于状态交互而创建的具体服务实例。

  • 在紧密耦合的环境中灵活、动态地交换终结点信息，在这种环境中进行通信的各方共享一组有关在交互过程中使用的具体策略或协议的公共假设。

为了支持这些方案，我们定义了一种轻量级且可扩展的机制来动态地标识并说明各服务终结点和实例。 由于 WSDL 1.1 可扩展性模型当前的局限性，WSDL 1.1 服务和端口元素还无法用于以上所列的使用情形。 终结点引用可在逻辑上扩展 WSDL 说明模型（例如，portType、绑定，等），但并不取代该模型。 在以下情形中，将使用终结点引用而不使用 WSDL <service/> 元素：

  • 需要对有状态服务的具体实例进行标识，或需要传输其实例的具体配置细节。

  • 需要传递服务终结点的轻量级的、独立的说明。 尤其当各通信方已共享该终结点配置的详细信息，但又需要添加或更新一些具体的策略信息（一般是动态配置过程的结果）时，可能需要使用终结点引用。

2.1. 终结点引用的信息模型

一个终结点引用由下列抽象属性组成：

[address] ： URI （必需的）

用于标识终结点的一个地址 URI。 这可能是一个网络地址或一个逻辑地址。

[reference properties] : xs:any (0..unbounded).

一个引用可能包含很多独立的属性，而标识被传递的实体或资源需要这些属性。 引用标识属性是由 QName 命名的元素信息项，要把消息准确地分发到位于交互终结点端的各个终结点，这些属性是必需的。 这些属性的解释（与一般使用终结点引用一样）依赖于与该终结点进行交互时所用的协议绑定和数据编码。 下面的第 2.3 节定义了 SOAP 协议的默认绑定。

[selected port type] : QName （可选）

被传达的终结点的主 portType 的 QName。

[service-port] : (QName, NCName (0..1)) （可选）

这是用于标识 WSDL 服务元素的 QName，该元素中包含被传达的终结点的定义。 服务名称提供一个指向服务终结点完整描述的链接。 一个可选的非限定名（non-qualified name）标识服务中与该终结点相对应的具体端口。

[policy] : wsp:policy (0..unbounded)

WS-Policy [18] 中说明的一些 XML 策略元素描述了终结点的行为、需求和能力。 策略可包含在终结点中，以便耗费资源的应用程序更容易地处理相应的策略，或者因为该策略是动态生成的。

2.2. 终结点引用 XML 信息集表示

本节定义了终结点引用作为 XML 类型 (

wsa:EndpointReferenceType

) 和一种 XML 元素 (FakePre-9b147590c3ab412781a6897adc3086dc-d3d0a2fcc53e4d24913279af6241d1f5) 时的基于 XML 信息集的表示。

只要 Web 服务被引用，即使用

wsa:EndpointReferenceType

类型。 以下说明了这种类型的内容： FakePre-0be2114002074e39bc4540d3263ad949-a1fc158b7bf6441d90e9c66bc1aad0d9

以下内容说明了上面架构概述中所列的属性和元素：

/wsa:EndpointReference

它代表一些

wsa:EndpointReferenceType

类型的元素。 本示例使用预定义的 FakePre-11b4f39b01154dd18ccb4a6ec40716c4-633cf5c13c7c499ebf3afefe3e2a3dad元素，但任何 wsa:EndpointReferenceType 类型的元素它都可以使用。

/wsa:EndpointReference/wsa:Address

这个必需的元素（xs:anyURI 类型）指定终结点引用的 [address] 属性。 这个地址可能是服务终结点的逻辑地址或标识符。

/wsa:EndpointReference/wsa:ReferenceProperties/

这个可选元素包含用于传递引用的 [reference properties] 的元素。

/wsa:EndpointReference/wsa:ReferenceProperties/{any}

ReferenceProperties 的每个子元素都代表一个单独的 [reference property]。

/wsa:EndpointReference/wsa:PortType

此可选元素（xs:Qname 类型）指定终结点引用的 [selected port type] 属性值。

/wsa:EndpointReference/wsa:ServiceName

此可选元素（xs:QName 类型）指定

<wsdl:service>

定义，该定义包含被引用终结点的 WSDL 描述。

/wsa:EndpointReference/wsa:ServiceName/@PortName

此可选属性（xs:NCName 类型）指定与被引用终结点相对应的

<wsdl:port>

定义的名称。

/wsa:EndpointReference/wsp:Policy

此可选元素指定关于如何与终结点进行交互的策略。

/wsa:EndpointReference/{any}

这是一种扩展性机制，用以允许指定其他元素。

/wsa:EndpointReference/@{any}

这是一种扩展性机制，用以允许指定其他属性。

下面内容演示了终结点引用。 这个元素引用了 URI "http://www.fabrikam123.com/acct" 处的 "fabrikam:InventoryPortType" 类型的端口。

<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
    <wsa:Address>http://www.fabrikam123.com/acct</wsa:Address>
    <wsa:PortType>fabrikam:InventoryPortType</wsa:PortType>
</wsa:EndpointReference>

2.3. 绑定终结点引用

当需要将一条消息寻址到终结点时，可根据依赖于协议和数据表示（用于发送消息）的转换，将终结点引用中所包含的信息映射到该消息。 协议专有的映射（或绑定）将定义如何将终结点引用中的信息复制到消息和协议字段中。 此规范为终结点引用定义了 SOAP 绑定。 这种映射可以显式地由其他绑定（定义为 WSDL 绑定或策略）取代；然而，如果没有一种适用的策略声明必须使用不同的映射，即假定为使用此处所定义的 SOAP 绑定。 为确保与广泛的设备之间具有互操作性，所有符合规范的实施都必须支持 SOAP 绑定。

终结点引用的 SOAP 绑定是由以下两条规则定义的：

  • 终结点引用中的 [address] 属性被复制到 SOAP 消息中的 [destination] 标头字段。

  • 每个 [reference property] 元素成为 SOAP 消息中的一个标头块。 每个 [reference property] 的元素信息项（包括其所有的 [children] 和 [in-scope namespaces]）将作为标头块添加到新消息中。

下一个示例显示了如何利用终结点引用的默认 SOAP 绑定来构建一条寻址到该终结点的消息：

<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
    <wsa:Address>http://www.fabrikam123.com/acct</wsa:Address>
    <wsa:ReferenceProperties>
        <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
    </wsa:ReferenceProperties>
</wsa:EndpointReference>

根据先前所声明的映射规则，地址值被复制到 "To" 标头，而 "CustomerKey" 元素应该作为标头逐字复制到目标地址为该终结点的 SOAP 消息中。 该 SOAP 消息如下所示：

<S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"
         xmlns:fabrikam="... ">
   <S:Header>
     ...
     <wsa:To>http://www.fabrikam123.com/acct</wsa:To>
     <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
     ...
   </S:Header>
   <S:Body>
     ...
   </S:Body>
</S:Envelope>

3. 消息信息标头

本节定义消息信息标头的模型和语法。

消息信息标头通过下面的抽象属性从总体上增加消息：

[destination] : URI （必要的）

该消息的目标接收方地址。

[recipient] : 终结点引用（可选）

该消息的目标接收方的终结点引用。

[source endpoint] : 终结点引用（可选）

最初发出此消息的终结点的引用。

[reply endpoint] : 终结点引用（可选）

一个终结点引用，用于标识该消息应答的目标接收者。 在构建应答消息时，发送者应该使用要应答消息的 [reply endpoint] 的内容来构建应答消息。 如果没有 [reply endpoint]，发送者可以使用 [source endpoint] 的内容来构建应答消息。 如果消息的应答没有意义（例如，它是一条单向的应用程序消息），或者应答终结点已经通过其它方法传达给了接收方，则可以没有这个属性。 如果 [reply endpoint] 包含内嵌的策略，那么该策略必须是针对该终结点的完整策略。

[fault endpoint] : 终结点引用（可选）

一个终结点引用，用于标识与此消息相关错误的目标接收方。 在构建一条错误消息时，发送者应该使用要应答消息的 [fault endpoint] 的内容来构建错误消息。 如果没有 [fault endpoint]，发送者可以使用 [reply endpoint] 的内容来构建错误消息。 如果既没有 [fault endpoint] 也没有 [reply endpoint]，发送者可以使用 [source endpoint] 的内容来构建错误消息。 如果发送者接收不到错误消息（例如，它是一条单向应用程序消息），则可以没有这个属性。 如果 [fault endpoint] 包含内嵌的策略，那么该策略必须是针对该端点的完整策略。

[action] : URI （必要的）

一个标识符，用于唯一地（并且不透明地）标识消息所暗指的语义。

我们推荐将 [action] 属性的值作为与抽象 WSDL 构件（例如，目标终结点上可用的消息、操作和端口类型）相对应的 URI。 在这种情况下，由 "relates to" 属性确定操作 (action) 是请求还是响应（即消息的“方向”）。 预计将至少定义一个用来计算 WSDL 中 action 元素的可互操作的 URI 编码方案。 一个操作可能和一个使用 Policy 元素的操作的 WSDL 定义相关联；也可以用一个附加的 Policy 元素识别用于根据终结点的 WSDL 定义计算 action 元素 URI 的算法。 最后，我们可以将任意的 URI 与一个操作显式关联在一起，并以此来取代所有已声明的编码算法。 这种方法支持自下而上的开发模型。

[message id] : URI （可选的）

一个 URI，用于从时间和空间上唯一地标识此消息。 任意两条消息都不能共用一个 [message id] 属性。 该属性的值是一个不透明的 URI，并且本规范中没有定义该 URI 除 equivalence 的额外解释。

[relationship] : (QName, URI) (0..unbounded)

一对数值，用于说明一条消息如何与另一条消息相关联。 关系的类型用 QName 来标识。 相关的消息是通过与该相关消息的 [message id] 属性相对应的 URI 来标识的。 消息标识符 URI 可以引用具体的消息，或者也可以是以下众所周知的 URI，它代表“未指定的消息”：

https://schemas.xmlsoap.org/ws/2003/03/addressing/id/unspecified

此规范有一个预定义的关系类型：

QName 说明

wsa:Response指明这是对 URI 所标识的消息的响应。

分配传入的消息是基于三种消息属性而进行的。 必要的 "destination" 和 "action" 字段分别标识目标处理位置和该消息的动词或意图。 对于请求 — 响应操作，"relates to" 字段可以区分请求和响应消息。

由于当前网络技术得到广泛使用（例如，NAT、DHCP、防火墙），很多部署都不能为给定的终结点分配一个有意义的全局 URI。 为了允许这些“匿名”终结点启动消息交换模式并接收响应，WS-Addressing 定义了以下已知 URI，以供那些不具备稳定且可解析的 URI 的终结点使用。

https://schemas.xmlsoap.org/ws/2003/03/addressing/role/anonymous

如果请求的 [reply endpoint] 和/或 [fault endpoint] 使用了此地址，则这些请求必须提供某种带外机制以便传递响应或错误。 这种机制可以是一种简单的请求/答复传输协议（例如，HTTP GET 或 POST）。 这种机制绝不可以用在标识目标终结点的终结点中。

3.1. 消息信息标头 XML 信息集表示

消息信息标头块提供消息的端到端特性，该消息可作为一个单元而容易地加以保护。 这些标头中的信息是不变的，并且不打算在消息的传输路径上被修改。

以下内容说明了消息信息标头块中的内容：

  <wsa:MessageID> xs:
anyURI 
</wsa:MessageID>
  <wsa:RelatesTo RelationshipType="..."?>
xs:anyURI
</wsa:RelatesTo>
  <wsa:To>
xs:anyURI
</wsa:To>
  <wsa:Action>
xs:anyURI
</wsa:Action>
  <wsa:From>
endpoint-reference
</wsa:From>
  <wsa:ReplyTo>
endpoint-reference
</wsa:ReplyTo>
  <wsa:FaultTo>
endpoint-reference
</wsa:FaultTo>
  <wsa:Recipient>
endpoint-reference
</wsa:Recipient>

以下内容描述了以上架构概述中所列的属性和元素：

/wsa:MessageID

此可选元素（xs:anyURI 类型）提供 [message id] 属性。

/wsa:RelatesTo

这个可选的（重复的）元素信息项以（URI、QName）对的形式提供了一个抽象 [relationship] 属性的值。 这个元素（具有 xs:anyURI 类型）的 [children] 属性提供相关消息的 [message id]

/wsa:RelatesTo/@RelationshipType

此可选属性（具有 xs:QName 类型）以 QName 的形式提供关系类型。 如果不提供这个属性，则其隐含值为 wsa:Response。 /wsa:ReplyTo

此可选元素（具有

wsa:EndpointReferenceType

类型）提供 [reply endpoint] 属性的值。

/wsa:From

此可选元素（具有

wsa:EndpointReferenceType

类型）提供 [source endpoint] 属性的值。

/wsa:FaultTo

此可选元素（具有

wsa:EndpointReferenceType

的类型）提供 [fault endpoint] 属性的值。

/wsa:To

此必要元素（具有

xs:anyURI

类型）提供 [destination] 属性的值。

/wsa:Action

此必要元素（具有 xs:anyURI 类型）提供 [action] 属性。 此元素的 [children] 提供此属性的值。

/wsa:Recipient

此可选元素（具有

wsa:EndpointReferenceType

类型）提供接收方的完整终结点引用。 发送方可以选择添加此标头，以用作下游节点的处理提示。

在包含消息信息标头块的消息响应中生成的消息应该包含应答消息中的消息信息标头块。

以下示例演示了如何在 SOAP 1.2 消息中使用消息信息标头块：

<S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope"
  xmlns:wsa="https://schemas.xmlsoap.org/ws/2003/03/addressing"
  xmlns:f123="http://www.fabrikam123.com/svc53" 
>
  <S:Header>
    <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff
    </wsa:MessageID>
    <wsa:RelatesTo>uuid:11112222-3333-4444-5555-666666666666
    </wsa:RelatesTo>
    <wsa:ReplyTo>
      <wsa:Address>http://business456.com/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:FaultTo>
      <wsa:Address>http://business456.com/deadletters</wsa:Address>
    </wsa:FaultTo>
    <wsa:To S:mustUnderstand="1">mailto:joe@fabrikam123.com</wsa:To>
    <wsa:Action>http://fabrikam123.com/mail#Delete</wsa:Action>
  </S:Header>
  <S:Body>
    <f123:Delete>
      <maxCount>42</maxCount>
    </f123:Delete>
  </S:Body>
</S:Envelope>

此消息应具有以下属性值：

[destination] URI joe@fabrikam123.com.

[reply endpoint] [address] 为 http://business456.com/client1 的终结点。

[fault endpoint] [address] 为 http://business456.com/deadletters 的终结点。

[action] http://fabrikam123.com/mail\#Delete

[message id] uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff

[relationship](wsa:Response,uuid:11112222-3333-4444-5555-666666666666)

4. 安全性注意事项

强烈推荐您使用 WS-Security [15] 中说明的机制来保护服务间的通信。为适当地保护消息，需要将主体和所有相关的标头都包含在签名中。具体来说，本规范中描述的消息信息标头（例如，<wsa:To>）需要与主体一同签名以将两者“绑定”在一起。对于传输过程中经过多个中间方的消息来说，应该注意的是当消息抵达最终的接收者时，一些或所有的消息信息头可以有多个签名。我们强烈推荐最初的发送者使用签名以防止被中间方欺骗。

无论何时，只要指定一个地址（例如，<wsa:From>、 <wsa:ReplyTo>、 <wsa:FaultTo> ……），处理器都应该验证：签名与声明一起提供，从而允许该签名代表指定的目标，以防止某些类型的攻击。

消息信息标头块可以加密其内容以实现端到端的机密，但应该小心以确保中间的处理器可以访问所需的信息（例如，<wsa:To>）。

在某些情况下，中间方可以添加额外的消息信息标头。如果出现了多个完全相同的标头，应该将它们针对不同的 SOAP 操作者／角色。如果为同一个操作者／角色指定了多个标头（并且出现了互相冲突的信息），处理器应该倾向于来自最初发送者（或其代表）的信息，除非处理器有额外的信息使它能够做出正确的决定并避免明显的安全攻击。

为了检测消息的重放，一些处理器可以缓存消息标识（<wsa:MessageID>）。

以下列表总结了几类常见的、适用于本规范中机制的攻击，并标识了阻止／减轻这些攻击的机制：

  • 消息变化 — 通过使用 WS-Security 包含消息信息的签名来阻止消息发生变化。

  • 消息泄露 — 通过使用 WS-Security 对敏感数据进行加密来保护消息的机密性。

  • 地址欺骗 — 确保所有地址都是由被授权代表地址的一方签署的，从而防止地址欺骗。

  • 密钥完整性 — 通过使用尽可能强壮的算法可以维护密钥的完整性（通过比较安全的策略 — 请参阅 WS-Policy [18] 和 WSSecurityPolicy [16]）。

  • 责任 — 责任是所使用的密钥和算法的字符串和类型的功能。在许多情况下，一个强壮的对称密钥提供足够的责任。 然而，在某些环境中，需要使用强壮的 PKI 签名。

  • 可用性 — 所有可靠的消息处理服务都会受到多种可用性攻击的影响。重放检测是一种常见的攻击，我们“推荐用 WS-Security 中描述的机制和／或通过高速缓存消息的标识来防止这种攻击。其他攻击（比如网络级的拒绝服务攻击）更难避免，也超出了本规范的范围。

5. 致谢

Michael Coulson，Microsoft；Giovanni Della-Libera，Microsoft；Christopher Ferris，IBM；Tom Freund，IBM；Steve Graham，IBM；Maryann Hondo，IBM；Efim Hudis，Microsoft；John Ibbotson，IBM；Gopal Kakivaya，Microsoft；Al Lee，Microsoft；Anthony Nadalin，IBM；Martin Nally，IBM；Henrik Frystyk Nielsen，Microsoft；Jeffrey Schlimmer，Microsoft；Keith Stobie，Microsoft

6. 参考资料

  • 1.B. Carpenter，Y. Rekhter，"Renumbering Needs Work"，RFC 1900，IAB，1996 年 2 月

  • 2.S. Bradner，"Key words for use in RFCs to Indicate Requirement Levels"，RFC 2119，Harvard University，1997 年 3 月

  • 3.T. Berners-Lee，R. Fielding，L. Masinter，"Uniform Resource Identifiers (URI): Generic Syntax"，RFC 2396，MIT/LCS，U.C. Irvine，Xerox Corporation，1998年 8 月

  • 4.R. Hinden，B. Carpenter，L. Masinter，"Format for Literal Ipv6 Addresses in URL's"，RFC 2732，Nokia，IBM，AT&T，1999 年 12 月

  • 5.W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)"，Tim Bray，Jean Paoli，C. M. Sperberg-McQueen，Eve Maler，2000 年 10 月 6 日（参见 "http://www.w3.org/TR/2000/REC-xml-20001006"）

  • 6.W3C Recommendation "Namespaces in XML"，Tim Bray，Dave Hollander，Andrew Layman，1999 年 1 月 14 日（参见 "http://www.w3.org/TR/1999/REC-xml-names-19990114/"）

  • 7.W3C Recommendation "XML Information Set"，John Cowan，Richard Tobin，2001 年 10 月 24 日（参见 "http://www.w3.org/TR/2001/REC-xml-infoset-20011024/"）

  • 8.W3C Recommendation "XML Schema Part 1: Structures"，Henry S. Thompson，David Beech，Murray Maloney，Noah Mendelsohn，2001 年 5 月 2 日（参见 "http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/"）

  • 9.W3C Recommendation "XML Schema Part 2: Datatypes"，Paul V. Biron，Ashok Malhotra，2001 年 5 月 2 日（参见 "http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/"）

  • 10.W3C Recommendation "XML Base"，Jonathan Marsh，2001 年 6 月 27 日（参见 "http://www.w3.org/TR/2001/REC-xmlbase-20010627/"）

  • 11.W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework"，Martin Gudgin，Marc Hadley，Jean-Jacques Moreau，Henrik Frystyk Nielsen（参见 "http://www.w3.org/TR/2002/WD-soap12-part1-20020626/"）。 此文尚在编写过程中。

  • 12.M. Baker，M. Nottingham，"The 'application/soap+xml' media type"，Internet-Draft draft-baker-soap-media-reg-01，2002 年 6 月。此文尚在编写过程中。

  • 13."Web Services Description Language 1.1"，Ariba，IBM，Microsoft，2001 年 2 月（位于 " http://www.w3.org/TR/wsdl"）

  • 14."Business Process Execution Language for Web Services"，BEA，IBM，Microsoft，2002 年 8 月（位于 "https://msdn.microsoft.com/library/en-us/dnbiz2k2/html/bpel1-0.asp"）

  • 15."Web Services Security Language"，IBM，Microsoft，VeriSign，2002 年 4 月。

  • 16."Web Services Security Policy Language"，IBM，Microsoft，RSA Security，VeriSign，2002 年 12 月。

  • 17."Web Services Trust Language"，IBM，Microsoft，RSA Security，VeriSign，2002 年 12 月。

  • 18."Web Services Policy Framework"，BEA，IBM，Microsoft，SAP，2002 年 12 月。

转到原英文页面