Scott Seely
Microsoft
Corporation
2002 年 10 月
适用于：
Web
服务规范（WS-Security、WS-Security Addendum）
摘要：
本文介绍如何使用
WS-Security 在 SOAP 消息中嵌入安全机制，并介绍 WS-Security 所涉及的三个方面：身份验证、签名和加密。（14
页打印页）
本页内容
|
简 介 |
|
|
日 常生活中的类似情况 |
|
|
对 SOAP 消息应用现有概念 |
|
|
WS-Security SOAP 标头 |
|
|
小 结 |
|
|
资 源 |
简介
在介绍
WS-Security 之前，我们有必要了解一下 WS-Security 存在的原因。很多刚刚接触 Web 服务的人都将 SOAP 看作是通过
HTTP 在两个端点之间交换消息的方法。通过 HTTP
可以验证调用方的身份、对消息签名以及对消息内容加密。这可以在以下几方面确保消息的安全性：调用方是已知的，消息接收方可以验证消息在传输过程中没有被
更改，监视网络通信的实体无法识别出所交换的数据。但是如果准备采用 SOAP 消息传递来解决某些复杂问题，则仅仅基于 HTTP
的安全性是不够的。这些复杂问题通常涉及沿着比请求/响应更为复杂的路径发送消息，或者不使用 HTTP
进行传输。调用方以及消息的标识、完整性和安全性需要在多个跃点中保留。沿路由可能需要多个加密密钥。此外还要跨越信任域。HTTP
及其安全机制只面向点到点的安全性。而更复杂的解决方案则需要端到端的安全性。WS-Security
解决的是如何在多点消息路径中维护一个安全的环境。
注
本文假设读者已经熟悉XML 标准
、XML 签名
和XML 加密
。
WS-Security 通过利用现有标准和规范来实现安全性，这样就不必在
WS-Security 中定义一个完整的安全性解决方案了。业界已经解决了许多此类问题。例如 Kerberos 和 X.509
用于身份验证；X.509 还使用现有的 PKI 进行密钥管理；XML 加密和 XML 签名描述了 XML 消息内容的加密和签名方法；XML
标准描述了为签名和加密而准备 XML 的方法。WS-Security 在现有规范中添加了一个框架，用于将这些机制嵌入到 SOAP
消息中。这是以一种与传输无关的方式完成的。
WS-Security 定义了一个用于携带安全性相关数据的 SOAP 标头元素。如果使用
XML 签名，此标头可以包含由 XML
签名定义的信息，其中包括消息的签名方法、使用的密钥以及得出的签名值。同样，如果消息中的某个元素被加密，则 WS-Security
标头中还可以包含加密信息（例如由 XML 加密定义的加密信息）。WS-Security 并不指定签名或加密的格式，而是指定如何在 SOAP
消息中嵌入由其他规范定义的安全性信息。WS-Security 主要是一个用于基于 XML 的安全性元数据容器的规范。
除了利用其他
现有的消息身份验证、完整性和加密外，WS-Security 还提供了什么？它指定了一个通过UsernameToken
。元素传输简
单用户凭据的机制。此外，为了发送用于加密或签名消息的二进制令牌，还定义了一个BinarySecurityToken
。在此标头中，消
息可以存储关于调用方、消息的签名方法和加密方法的信息。WS-Security 将所有安全信息保存在消息的 SOAP 部分中，从而为 Web
服务安全性提供了端到端的解决方案。
在本文中，我们将了解如何使用 WS-Security 和其他配合工具在 SOAP
消息中嵌入安全机制。我们将了解 WS-Security 所涉及的三个方面：
| • |
身份验证 |
| • |
签名 |
| • |
加密 |
这
三方面体现了安全性的重点，并回答了以下问题：
| • |
我的授权对象是谁？ |
| • |
消息在跃点之间是否被修改过？ |
| • |
消息是否来自预期的 |
| • |
如何隐藏只希望特定对象看到的内容？ |
首
先，我们看一看日常生活中的一些类似情况。
日常生活中的类似情况
要了解 WS-Security
的功能，首先可以看一下现实生活中的类似情况。具体地说，您在日常生活中何时以及如何使用证件？毕竟日常生活中始终离不开各种证件。如果有人要求您证明自
己的年龄，您会从钱包中拿出驾驶执照。如果您不用现金支付商品货款，便会使用信用卡向贷方机构证明自己的身份。在跨越边境或在国外时，您需要使用护照证明
自己的身份。所有这些都是证件。其作用是说明信用卡、驾驶执照和护照的所有人与证件中的人相符。但是它们并不验证您的身份。验证是一种行为，而证件本身并
不能实施这一行为。当使用书面证件时，人是身份验证的执行者。那么验证过程是如何实现的呢？
当您出示驾驶执照或护照时，查看证件的人将执行
一些操作来验证证件是否真实，以及您是否是这些证件的合法所有者：
| • |
这两种证件都包含证件注册持有者的照片和其他身份特征：身高、体重和眼睛的颜色。查看证件的人可以确保您与证 |
| • |
证件都有一定的有效期限。这样可以确保证件中的描述数据是最新的数据。 |
| • |
证件中包含签名，可 |
这
些证件还有其他一些重要特征。证件上的标记可以使人快速验证证件的真伪。证件是由我们信任的能够提供有效身份信息的机构签发的：地方或国家政府。上面还提
到了信用卡。它与驾驶执照和护照有所不同。
| • |
它们是由银行而不是政府发放的。 |
| • |
它们只包含用于识别持 |
| • |
只有在出示其他支持性证件（如政府签发的 ID）时，它们才能用来验证身份。 |
那
么像信用卡这类证件能够做些什么呢？
信用卡通常只依赖签名进行身份验证。有些信用卡带有照片，以增加身份验证的可靠性。由于信用卡提供的身
份验证不够充分，因此许多机构要求随信用卡同时出示政府签发的
ID。就安全性而言，当您出示信用卡时，您就是在声明您有权购买商品和服务，并且向您提供信用卡的机构将向商家支付款项。商家可以通过将政府签发的带照片
的 ID 与您本人进行比较，以确认您是有效的持卡者。（当然，如果您通过电话或 Internet
进行交易，则另当别论，但这也说明在这些领域还存在着其他安全机制。）
对 SOAP 消息应用现有概念
WS-Security
试图将大量有关标识和身份验证概念引入到 SOAP 消息领域。要使 SOAP 消息具有实用价值，消息中必须包含能够完成以下任务的信息：
| • |
标识消息涉及的一个或 |
| • |
证明实体具有正确的组成员身份。 |
| • |
证明实体具有正确的访 |
| • |
证明消息未被更改过。 |
最后，我们还需要一
种机制，使信息对于未获授权者保密。在日常的个人身份验证中，我使用自己的驾驶执照或护照证明我的身份；通过会员卡证明自己拥有某些权利；使用钱包中的信
用卡，我可以购买商品和服务，从图书馆借书，向我的保险商出示医疗费用单据，在本地的百货商店享受优惠。WS-Security 允许对 SOAP
消息应用同样的概念。通过使用安全令牌来标识调用方并声明它的权限，消息可以包含以下信息：
| • |
调用方标识：我是用户 Joe。 |
| • |
组成员身份：我是 |
| • |
权限声明：因为我是 ColdRooster.com |
要
创建一条消息，使其能够在使用了身份验证技术（例如 Kerberos）的 ColdRooster.com
服务器上创建新的数据库，应用程序必须获取一些安全令牌。首先，创建此消息的应用程序需要获取一个安全令牌，以证明该应用程序是在代表用户 Joe
执行操作。用户 Joe 在通过用户名/密码登录或使用智能卡登录时提供此令牌。假设系统的安全结构使用 Kerberos，并假设 Joe
使用的环境具有一个密钥发行中心，用于在 Joe 登录时授予其 Ticket Granting Ticket (TGT)。当 Joe 决定在
ColdRooster.com 上创建新数据库时，此环境转到 Ticket Granting Service，并请求一个表明 Joe 有权在
ColdRooster.com 上创建新数据库的 Service Ticket（服务票据）。环境在获取服务票据 (ST) 后，将其提供给
ColdRooster.com 的数据库服务器。数据库服务器验证该票据的有效性，然后允许 Joe 创建新的进程。
WS-Security
试图将上述安全性交互过程封装到一组 SOAP 标头中。WS-Security 通过两种方法处理凭据的管理。如果 Web
服务使用自定义身份验证，则它定义一个专门元素 UsernameToken
，用于传递用户名和密码。WS-Security
还提供了一个用于提供二进制身份验证令牌（如 Kerberos 票据和 X.509 证书）的元素：BinarySecurityToken。
图
1 显示了比较常见的消息流形式。
图
1.
典型的消息流
安全令牌服务可以是 Kerberos、PKI
或用户名/密码验证服务。此服务可能不基于 Web 服务。事实上，Kerberos 服务票据允许通过 Kerberos
协议（使用操作系统的安全性功能）来访问服务。在获取要在消息中使用的令牌后，客户端将这些令牌嵌入到消息中。客户端应该使用只有他们了解的数据对消息进
行签名。服务器能够用多种方式推断出此签名。如果客户端使用 UsernameToken
进行身份验证，则客户端应该发送散列密码并使用
此密码对消息进行签名。如果服务器为消息生成的签名与消息中包含的签名相匹配，服务器便可以验证客户端发送的消息。
当使用 X.509
证书时，可以使用私钥对消息进行签名。消息应该在BinarySecurityToken
中包含证书。当使用 X.509 时，了解
X.509 公钥的所有人都可以验证此签名。最后，如果使用 Kerberos，则可以使用 Kerberos
票据中嵌入的会话密钥对消息进行签名或加密。由于 Kerberos
票据将为令牌的接收方锁定，因此只有接收方能够将此票据解密，发现会话密钥，并验证签名。
如果身份验证很重要，则对 SOAP
消息进行签名或加密是很关键的。为什么是这样呢？因为仅把有效的身份令牌添加到消息中是不够的。攻击者可以从有效消息中取出这些令牌，并添加到自己的消息
中。我们还需要能够确定此消息是由消息中标识的对象创建的。如果不使用 XML 签名来签名消息，便不能说明消息未被更改或标识令牌没有被滥用。
至
此，相信您已经对 WS-Security 有所了解了。下面让我们更深入一些，来看个究竟。
WS-Security SOAP 标头
从本节开始直至最后，
我会使用一些 XML 代码片断。为了不必显示全部 XML 命名空间声明和弄乱代码片断，我使用了以下 XML 命名空间：
表
1
：
XML
命名空间
| 命名空间 | 说明 | 命名空间 URI |
|
Xs |
XML 架构 |
http://www.w3.org/2001/XMLSchema |
|
Wsse |
WS-Security |
http://schemas.xmlsoap.org/ws/2002/07/secext |
|
Wsu |
实用程序元素 |
http://www.w3.org/2001/XMLSchema |
|
Soap |
SOAP 元素 |
http://schemas.xmlsoap.org/soap/envelope/ |
WS-Security 规范定义了新的 SOAP 标头。为了解
WS-Security SOAP 标头包含的内容，我们首先看一看该元素的架构片断。
<xs:element name="Security">
<xs:complexType>
<xs:sequence>
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded">
</xs:any>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
如上所示，Security 标头元素允许在其中包含任何 XML
元素或属性。这使得标头能够适应应用程序所需的任何安全机制。如果这听起来有点怪，我们可以想一想 SOAP
标头和正文的工作方式。标头和正文都可以包含 XML 元素集合。除了不能包含 XML 处理指令外，SOAP 规范对这些元素的内容几乎未做任何声明。
由
于标头必须提供的功能，WS-Security
需要这种结构类型。它必须能够携带多个安全令牌以标识调用方的权限和身份。如果消息已经过签名，标头必须包含关于消息的签名方式和密钥信息存储位置的信
息。密钥可能包含在消息中或存储在其他地方，并且仅供引用。最后，关于加密的信息也必须能够包含在此标头中。
那么，中间方如何知道它所拥有
的 WS-Security？一个 SOAP 消息可能包含多个 WS-Security 标头。每个标头都由唯一的 actor 标识。两个
WS-Security 标头不能使用相同的 actor 或省略 actor。这使得中间方很容易识别哪个 WS-Security
标头包含它们所需要的信息。当然，中间方确实需要知道它所处理的 actor URI。要将 URI 与 actor
关联在一起，并确保中间方知道要执行的操作，必须通过编程来实现。任何 SOAP 标头中的 actor 属性都表明“此标头适用于在 actor
URI 指示的范围内作用的任何端点”。URI 的含义是由构造 Web
服务的工作组提供的。这意味着中间方可以在各种范围内进行操作。结果，此中间方可能不使用或使用一个或多个标头。确实如此，它甚至会使用多个安全性标头。
WS-Security
补遗
在介绍完 WS-Security 后，有几项需要重点加以说明，特别是就安全性方面。此外，还需要为通常的
Web 服务指定一些附加项。本文涵盖了补遗中适用于安全性的部分。在本节中，我想介绍两个并非专用于安全性的项目：wsu:Id
和
wsu:Timestamp
。补遗中明确说明了这两项的功能和用法。
wsu:Id
Id
属
性使用 XML 架构 ID 类型。添加此元素是为了简化 Web 服务中间方和接收方的处理。此属性的值不能复制到文档中的其他位置。除了作为 GXA
规范中的独特标识符外，该补遗并未深入规定此元素的用法。这样其他规范便可以自行限制Id
的使用。
wsu:Timestamp
在
面向消息的系统中，一个常见的问题就是数据的有效期限。太旧的数据将被丢弃。如果收到两个相互冲突的消息，则可以使用相关的时间戳来确定哪个消息被执行，
哪个被忽略。为处理 WS-Security 中出现的以及将在其他 GXA 规范中出现的与时间有关的问题，定义了wsu:Timestamp
元素和几个 helper 元素。
在消息的生存期中，比较重要的几项是消息的创建时间、发送方要求消息过期的时间和消息的接收时
间。知道了创建时间和过期时间，接收方便可以确定数据是否足够新以供其使用，或者数据是否太旧以至应该丢弃。包含这一数据的元素包括：
| • |
wsu:Created |
| • |
wsu:Expires |
| • |
wsu:Received |
以上所有元素可能单独出现，也可能作为wsu:Timestamp
元素的一部分出现。每个元素都可以包含wsu:Id
属性来唯一标识该项。默认情况下，这些时间戳以xs:dateTime
类型的形式表示时间。为针对其他非标准时间戳（可能用于其他问题领域）提供一定的灵活性，其中每一项还包含了一个名为ValueType
的
属性。如果时间以xs:dateTime
的形式表示，则不必使用此属性。
wsu:Received
元素还
允许使用wsu:Created
或wsu:Expires
所没有的两个额外属性。该元素可以使用Actor
属
性和以毫秒计的延迟量来表示其相关 actor 的 URI。延迟是由该 actor 使用Delay
属性所致。
如前所
述，您可以在其他结构中使用wsu:Received
、
wsu:Created
和 wsu:Expires
元素。例如，我们经常可以看到用wsu:Created
元素来指示特定元素添加到消息的时间。当指示关于消息的更多信息，并且
一次使用多个元素时，可以将这些元素包装到 wsu:Timestamp
元素中。在一个时间戳中，这三种元素每个只能出现一次。时间戳在
消息中可以作为一个整体使用，此时它将以 soap:Header
节点的子节点形式出现。例如，某个消息可以使用以下wsu:Timestamp
标
头，指示它在未来五分钟内有效：
<wsu:Timestamp>
<wsu:Created wsu:Id=
"Id-2af5d5bd-1f0c-4365-b7ff-010629a1256c">
2002-08-19T16:15:31Z
</wsu:Created>
<wsu:Expires wsu:Id=
"Id-4c337c65-8ae7-439f-b4f0-d18d7823e240">
2002-08-19T16:20:31Z
</wsu:Expires>
</wsu:Timestamp>
至此，相信您已掌握了足够的背景信息。下面我们来深入了解如何使用 WS-Security 实现身份验证、签名和加密。
身
份验证
WS-Security 提供了无限多种方法来验证用户。规范中说明了其中的三种方法：
| • |
用户名/密码 |
| • |
通过 X.509 |
| • |
Kerberos |
在本节中，我们将了解
这些身份验证方法的工作原理，以及如何将此信息编码到 SOAP 消息中。
用户名
/
密码
用
于传递调用方凭据的最常见方法之一是使用用户名和密码。这是一项用于 HTTP 基本身份验证和简要身份验证的技术。实际上，如果您熟悉 HTTP
简要身份验证的工作原理，就可以灵活地运用这一身份验证机制。为了以此方式传递用户凭据，WS-Security 定义了UsernameToken
元
素。此元素的架构如下：
<xs:element name="UsernameToken">
<xs:complexType>
<xs:sequence>
<xs:element ref="Username"/>
<xs:element ref="Password" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Id" type="xs:ID"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
</xs:element>
此架构片断引用了两个其他类型：Username
和Password
。这两种类型实质上是字符串，根据
需要可以包含额外属性。Password
包含一个名为Type
的属性，指示密码的传递方式。密码可以采用纯文本或简要格式传
递。当在 SOAP 消息中传递UsernameToken
时，XML 可能包含类似如下的内容：
<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>
以上是以纯文本格式发送的密码示例。该解决方案看上去很容易遭到破坏。如果希望以更安全的方式发送密码，可以发送它的简要散列。
<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordDigest">
KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
<wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
<wsu:Created xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
2002-08-19T00:44:02Z
</wsu:Created>
</wsse:UsernameToken>
使用 SHA1 散列会使密码变得不易识别，因而可以增加安全性。密码简要散列是随机内容、创建时间与密码的组合。随机内容的长度是
16 字节，以 base64
编码值的形式传递。其工作原理是客户端使用所有这些信息加上密码来创建密码散列。接收方通过获取其中的密码并再次创建散列来验证此数据。如果结果一致，则
表明密码正确。但这种保护方式不能防范重复攻击。如果使用这种保护方式，请确保包括一个wsu:Timestamp
标头，其中包含一个足够
小的时间，用以提供创建时间值和过期时间值。然后，对消息中的wsu:Timestamp
元素进行签名，以便可以检测到对时间戳的任何篡
改。否则，攻击者可能使用完整的UsernameToken
攻击您的 Web
服务。为防范重复攻击，您还需要包含一个机制，用于跟踪传入消息的某个唯一特性。这种机制需要将此特性保存到缓存中，并且至少持续到消息超时。
X.509
证书
验证用户身份时，另一个选择是发送 X.509 证书。X.509 证书确切告诉您用户的身份。您可以使用
PKI
将此证书映射到您应用程序中的现有用户。使用证书来验证自己非常容易受到重复攻击的破坏。因此，最好强制消息发送方同时使用他们的私钥来签名消息。这样，
当解密消息时，您会知道它确实来自该用户。
当消息发送 X.509 证书时，将在一个名为BinarySecurityToken
的
WS-Security 令牌中传递此证书的公共版本。证书本身以 base64 编码数据的形式发送。BinarySecurityToken
具
有如下架构：
<xs:element name="BinarySecurityToken">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Id" type="xs:ID" />
<xs:attribute name="ValueType" type="xs:QName" />
<xs:attribute name="EncodingType" type="xs:QName" />
<xs:anyAttribute namespace="##other"
processContents="strict" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
它最基本的结构包含一个字符串、一个唯一的标识符和一些指示所包含值的类型和编码形式的信息。ValueType
可以
是以下任何值（由 WS-Security 架构文档中的ValueTypeEnum
定义）：
| • |
wsse:X509v3 |
| • |
wsse:Kerberosv5TGT |
| • |
wsse:Kerberosv5ST |
如果您尚不理解这些 Kerberos
信息，我将在下一节中进行更详细的介绍。EncodingType
是另一种枚举。可以将它设置为 wsse:Base64Binary 或
wsse:HexBinary。您也许已经猜到，这个值只是表示所使用的编码方法。在 WS-Security 标头中，当传递 X.509
证书时，此元素类似于如下片断：
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa12764184f"
>MIIHdjCCB...</wsse:BinarySecurityToken>
请记住，在使用 X.509
证书时，您还要进行一些其他操作（例如签名消息）。使用证书的私钥创建的签名可以证明客户端是该证书的合法拥有者。这种消息可以被重复。为帮助防范与重复
相关的问题，您可以制订一个策略，说明消息在被忽略之前的有效时间。该时间应在wsu:Timestamp
元素（作为消息中的 SOAP
标头）中传递。
Kerberos
要使用 Kerberos，用户需要提供一组凭据（例如用户名/密码或
X.509 证书）。如果所有内容检验合格，安全系统将授予用户一个 TGT。TGT
是一个隐藏的数据，用户无法读取，但必须提供它才能访问其他资源。通常，用户需要提供 TGT 来获得服务票据 (ST)。系统的工作方式如下：
| • |
1.客户端到密钥发行 |
| • |
2.客户端获取 TGT 并使用它来访问 Ticket |
| • |
3.客户端为访问特定网络资源而请求一个 ST。然后，TGS |
| • |
4.客户端向网络资源出示此 ST，并使用 ST 指示的权限访问资源。 |
Kerberos
是很诱人的，因为它包含客户端向服务证明身份以及服务向客户端证明身份的机制。ST
只适用于访问一个网络资源，并可用于发现调用方的身份。当在消息中提供 Kerberos
票据时，需要将该数据加密复制到消息中。WS-Security 没有解释如何获取 TGT 和 ST。
签名
签
名后的消息几乎无法被篡改。消息签名不能禁止外部各方查看消息内容。使用签名，SOAP
消息的接收方可以知道已签名的元素在路由中未发生改变。只要可能，就应当使用 XML 签名对消息进行签名。为什么是这样呢？因为 XML
签名已经处理了许多难以描述的问题。WS-Security
只是简单解释了如何使用签名来证明消息没有被更改。上面提到的所有三种身份验证机制，都提供了对消息进行签名的方法，从而使您可以确定以下两个事项：
| • |
由 X.509 |
| • |
签名后的消息没有被 |
每种方法都提供了一个可用于签名消息的密钥。X.509
允许发送方使用他们的私钥来签名消息。Kerberos
提供了一个由发送方创建并在票据中传输的会话密钥，只有此消息的预期接收方可以读取票据，发现会话密钥并验证签名的可靠性。最后，可以使用密码对UsernameToken
进
行签名。
签名是使用 XML 签名生成的。要对“Hello World”这样简单的消息签名，消息中的每个元素几乎都需要单独进行签名。wsu:Timestamp
存在一个有趣的问题，因为中间方可能会向wsu:Timestamp
中添加一个wsu:Received
元素。
每当元素发生改变时，都需要更新签名，否则将出现异常。为什么是这样呢？因为如果内容发生改变，签名便不再匹配。在 SOAP
消息中，签名和所需的额外数据添加了大量额外信息。
加密
有时，仅仅证明消息发送方的身份和表明消息未经更改仍
然不够。如果您通过签名的纯文本来发送信用卡号或银行帐号，攻击者实际上可以验证没有其他攻击者更改过消息的内容。因此，他们可以十分肯定数据是有效的。
这对您当然不妙。为此，您需要加密数据，使得只有预期的接收方才能够阅读您的消息。监视网络交换的任何人都不应该知道消息内容。与处理消息签名一
样，WS-Security 为此也提供了相应规范，采用了现有标准，并且能够很好地完成加密工作。实际上，它们并入了 XML 加密。
加
密数据时，可以选择使用对称加密或不对称加密。对称加密需要一个共享密钥。也就是说，加密消息与解密消息使用的是同一个密钥。如果您同时控制两个端点并且
可以信任使用密钥的用户和应用程序，则可以使用对称加密。对称加密在密钥分发上存在一点问题。在某个时间点上，密钥需要发送给接收方。如何实现这一点呢？
是否要在需要时通过邮寄磁盘提供或协商确定？这两种方法都可以。
如果您需要使用简单的分布式密钥来发送数据，则可以使用不对称加密。
X.509
证书允许使用不对称加密。接收数据的端点可以公布它的证书，并允许任何人使用公钥来加密信息。只有接收方知道私钥。因此，只有接收方可以得到加密的数据并
将其重新转换为可读内容。
那么，加密后的消息是什么形式呢？如果使用的是
Triple-DES，则发送方和接收方都必须以某种安全的方式交换密钥。对称密钥可以隐藏在 Kerberos 票据内，或被取出交换。基于
WS-Security 并带有嵌入的 XML 加密信息的消息类似于如下所示：
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<soap:Header
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsu:Timestamp>
<wsu:Created
wsu:Id="Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"
>2002-08-22T00:26:15Z</wsu:Created>
<wsu:Expires
wsu:Id="Id-10c46143-cb53-4a8e-9e83-ef374e40aa54"
>2002-08-22T00:31:15Z</wsu:Expires>
</wsu:Timestamp>
<wsse:Security soap:mustUnderstand="1" >
<xenc:ReferenceList>
<xenc:DataReference
URI="#EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" />
</xenc:ReferenceList>
<xenc:ReferenceList>
<xenc:DataReference
URI="#EncryptedContent-666b184a-a388-46cc-a9e3-06583b9d43b6" />
</xenc:ReferenceList>
</wsse:Security>
</soap:Header>
<soap:Body>
<xenc:EncryptedData
Id="EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Symmetric Key</KeyName>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue
>InmSSXQcBV5UiT... Y7RVZQqnPpZYMg==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>
上面的消息包含有关哪些数据被加密以及如何加密的信息。没有密钥的任何人都无法解密soap:Body
中的加密文本。
当
执行不对称加密时，消息的接收方需要知道私钥才能解密消息。公钥的交换必须提前进行。
小结
WS-Security 允许 SOAP
消息标识调用方、签名消息并加密消息内容。它尽可能使用了现有规范，以减少为安全传递 SOAP
消息所需的开发工作量。由于所有信息都在消息中传递，因此消息与传输方式无关，通过 HTTP、电子邮件或在 CD-ROM
上都可以进行安全的消息传递。