W3CHINA.ORG讨论区--Web 服务最佳实践，第 11 部分: Web 服务安全性，第 1 部分

贴子主题： Web 服务最佳实践，第 11 部分: Web 服务安全性，第 1 部分

本主题类别:

Web 服务安全性（WS-Security）的机制级别: 初级

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#author]Holt Adams[/URL], 资深咨询 IT 架构师, IBM jStart

2004 年 4 月 01 日

在当今世界里，开展业务通常需要公司在企业到客户（business-to-customer）和企业到企业（business-to-business）的交互中使用 Internet。通常，在业务事务中交换的消息是以任务为中心的、具有市场价值的、或者机密的；因而，当通过 Internet 传递时，必须保护它免受意外的访问或故意的未经授权的控制和使用。理解在面向服务的体系结构中实现 Web 服务安全性（WS-Security）的机制以及它所提供的选项，可以使您选出最好的安全性技术来处理您对验证、数据完整性和机密性的需求。
本文的主题将分成两部分来说明。第一部分介绍 Web 服务安全性（WS-Security）的特征、业务参与者之间的关系、以及实现 Web 服务安全性（WS-Security）的功能的机制。后一部分将概述 IBM WebSphere Application Server 对 Web 服务安全性（WS-Security）的支持、客户的业务需求以及他们如何将 Web 服务安全性（WS-Security）和其他的安全性技术用于他们的可操作解决方案。

引言

使用安全性的含义

满足安全性需求的设计选择和实现通常会对解决方案的性能有不利的影响。这并不意味着用于解决方案的所有安全性技术都将导致低的性能。相反，您应该意识到，需要对业务参与者的验证、消息内容的数字签名以及 XML 数据的加密的 Web 服务解决方案可能会有非常不同的性能特征，这取决于保护解决方案公开的业务功能和数据的技术和方法。

在本文中涉及的安全性的三个需求包括：（a）验证（authentication）、（b）数据完整性（data integrity）和（c）数据机密性（data confidentiality）。如果您对满足这些安全性需求的机制不熟悉，那么在深入探讨您可以如何实现它们zhiqian，我将简要地概述一下这些功能。

安全性的三个需求

验证（authentication）用来确保业务事务中的各方确实是他们所声称的；因而，身份证明是必需的。这个证明可以以不同的方式获得。一个简单的例子就是通过提交用户 ID 和密码。一个更复杂的例子是，使用由信任的认证机构（Certificate Authority）（比如 Verisign）签发的 X.509 证书。这个证书中包含身份凭证，并且具有一对与之相关联的私钥和公钥。由一方提交的身份证明包括证书本身以及单独一条使用证书的私钥数字签名的信息。通过确认使用与一方的证书相关联的公钥签名的信息，接收方可以验证发送方是证书的所有者，从而确认他们的身份。在双方彼此验证时，称作相互验证（mutual authentication），并且这种验证通常是在 Web 服务客户和 Web 服务提供者之间完成的。

为了确认在事务中交换的业务信息的完整性，确保在 Internet 上传送期间消息的内容没有被改变或破坏，可以使用安全性密钥对数据进行数字签名。这是安全性的三个需求中的第二个。一个常用的实践方法是使用发送方的 X.509 证书的私钥对 Web 服务请求的 SOAP Body 进行数字签名。类似地，也可以签署请求中的 SOAP 头代码块，以确保在实际业务上下文范围以外的事务中交换的信息的完整性（例如，消息 ID、安全性令牌）。同样地，还可以对 Web 服务响应进行数字签名，从而确保数据的完整性。

安全性的三个需求的第三个是机密性（confidentiality）。可以利用加密技术来使 Web 服务请求和响应中交换的信息不可读。这样做的目的是，确保访问传送中的、内存中的、或已经持久化的数据的任何人都将需要适当的算法和安全性密钥解密数据才能访问实际的信息。

现今，您可以使用各种各样的机制来实现所有这些安全性措施。基于您特定的需求和业务环境，您将可以在依赖于传输的和特定于 SOAP 消息传递的机制之间做出选择。

因为本文是 Web 服务最佳实践（Best Practices for Web services）系列的一部分，它将主要集中于在您的解决方案中利用 Web 服务安全性（WS-Security）的各种方法以及您应该预料到的性能影响。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

一般的 Web 服务安全性（WS-Security）模型

Web 服务安全性（WS-Security）规范处于 OASIS 标准组织内部最终批准的过程中，它所提供的机制满足了应用程序端点之间的安全性的三个需求。通过使用 Web 服务安全性（WS-Security），您可以有选择地实现安全性的三个需求中的每个需求，这样就能够在您的解决方案中就实现它们当中的一个或全部。

需要另一个应用程序的服务的应用程序在本文中被称为消费应用程序（Consuming Application）。我将提供服务的应用程序称为服务提供者（Service Provider）。下图说明了这种关系，它是后面我们大部分讨论的基础：

图 1 —— 系统环境

对于本文后面所描述和说明的场景，在调用服务提供者（Service Provider）的服务之前，服务提供者（Service Provider）的 X.509 证书的公钥必须同客户端交换，并配置在客户端的运行时中。对于消费应用程序（Consuming Application）和服务提供者（Service Provider），签发双方证书的认证结构（Certificate Authority）（比如 Verisign）的根证书将需要导入到本地的 keystores 中。消费应用程序（Consuming Application）的 keystore 将包含服务提供者（Service Provider）的证书的根证书。同样地，服务提供者（Service Provider）的 keystore 将需要消费应用程序（Consuming Application）的证书的根证书。上述要求是强制性的，这使得可以对单个证书的数字签名（作为 SOAP 消息中的二进制令牌传送）进行确认。

所有这三个安全性需求的完整实现将包括：

Web 服务的发送方进行请求或响应
使用它们的 X.509 证书的私钥来签署消息
使用接收方的 X.509 证书的公钥来加密消息，以便确保只有它们才能访问消息内容。
Web 服务的接收方进行请求或响应
使用发送方的公钥来检验消息的签名，以便验证发送方并确认消息的完整性
使用它们的 X.509 证书的私钥来解密消息

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

Web 服务安全性（WS-Security）XML 加密的细节

基于 Web 服务安全性（WS-Security）规范和它引用的 XML 加密规范的数据加密包括：

使用对称算法和非对称算法的两阶段过程。
一个共享密钥，用于使用像 Triple DESA 这样的对称算法来加密/解密数据。对称算法非常有效，并且可以与用于加密和解密计算的单一密钥一起使用。Web 服务安全性（WS-Security）实现使用一个随机生成的密钥。一旦消息的数据被加密，密钥本身就被插入到消息中。（请注意，正如下面所描述的，密钥同样也被加密了。）
在 SOAP 消息中传递共享密钥，带有使用非对称算法（比如 RSA-V1.5）加密/解密的密钥。共享密钥的加密与使用算法加密的消息数据不同，它使用的是一对密钥——一个私有的和一个公共的。X.509 证书有两个密钥，一个是证书的所有者私有的，而另一个是与他们一起开展业务的其他人共享的。对称算法要比非对称算法效率高；然而，它们需要管理双方之间共享的密钥，因而具有把共享的密钥暴露给您的组织或业务合作伙伴以外的其他人的内在安全性风险。因而，仅仅使用随机密钥的非对称算法，Web 服务安全性（WS-Security）就提供了一种相对高效又易于管理的解决方案。在本文的第 2 部分中，我将讨论之所以使用相对（relatively）这个词的原因。
请参阅在 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#5]参考资料[/URL]部分中的相关的链接，以获得 XML 加密的详细信息。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

现实世界中的 Web 服务安全性（WS-Security）场景

下面概述的场景是众多可以使用 Web 服务安全性（WS-Security）实现的可能性中的一个。它使用的是 X.509 证书，在很多客户解决方案中常见的一种实践，我将在本文的第 2 部分中概述它。

消费应用程序处理 Web 服务请求

典型地，消费应用程序（Consuming Application）将有一个服务代理（Service Proxy）或一个 JAX-RPC 存根组件（它是通过使用服务提供者（Service Provider）的 WSDL 从集成开发环境（Integrated Development Environment）（比如 WebSphere Studio Application Developer）生成的。当调用 Web 服务时，代理或客户端系统上的 SOAP 运行时会在发送请求之前执行 Web 服务安全性（WS-Security）功能。

首先，对 SOAP 消息进行数字签名。SOAP 运行时可以访问 keystore 以检索所需的安全性密钥和证书。取决于您的环境所提供的 Web 服务安全性（WS-Security）支持，您既可以仅仅对 SOAP 主体进行签名，也可以对 Body 内部的单个元素进行签名。另外，您还可以对 SOAP 头代码块进行签名。签名是利用消费应用程序（Consuming Application）的 X.509 证书的私钥来执行的。一旦消息被签名，X.509 证书本身就作为二进制安全性令牌包含进 SOAP 头了。消息是使用带有共享密钥的对称算法进行加密的。用于数据加密的密钥是使用带有与服务提供者（Service Provider）的 X.509 证书相关联的公钥的非对称算法进行加密的。一旦消息和共享密钥被加密，服务提供者（Service Provider）（请求正发送给它）的 X.509 证书的引用就包含进 SOAP 头了。之所以这样做，是因为服务提供者（Service Provider）可能会使用多个证书。

图 2 —— 消费应用程序使用 Web 服务安全性处理请求

服务提供者处理 Web 服务请求

当服务提供者（Service Provider）接收到 Web 服务请求时，基于请求者的 URL （所发布的服务访问端点），请求就定向到 SOAP 处理引擎（SOAP 运行时）。在请求中传送的消息数据和共享密钥是加密的，所以第一步就是识别 SOAP 头中引用的 X.509 证书，并从 keystore 中检索它的私钥。一旦获得私钥，就可以使用非对称算法来解密共享密钥。通过公开的共享密钥，就可以使用对称算法来解密消息数据。现在，通过公开的整个消息，就可以访问在 SOAP 头中传送的 X.509 证书来检索它的公钥。消息的数字签名是利用消费应用程序（Consuming Application）的公钥来执行的。作为签名成功确认的结果，服务提供者（Service Provider）的 SOAP 运行时（runtime）不仅确认消息的完整性，而且还确保消费应用程序（Consuming Application）确实对消息进行了签名。这一过程也验证了消息的来源/发送方，因为只有拥有这个证书的发送方才可以访问用来对消息进行签名的私钥。一旦消息被解密且确认了签名，SOAP 运行时（runtime）就可以调用 Web 服务的实现。

图 3 —— 服务提供者使用 Web 服务安全性处理请求

服务提供者处理 Web 服务响应

一旦执行了服务实现的业务逻辑并且获得了一个响应，同样的 Web 服务安全性（WS-Security）操作就在 Web 服务的响应消息上进行。然而，用于数字签名和加密的 X.509 密钥对的角色是颠倒的。服务提供者（Service Provider）的 SOAP 运行时使用它自己的 X.509 证书的私钥对消息进行数字签名。证书包含在 SOAP 消息中，并且使用共享密钥来加密这个消息。用于数字加密的密钥可能是在最初请求中传送的同一密钥，也可能是另一个随机生成的密钥，而后者更具代表性。共享密钥的加是使用在请求中传送的证书的公钥来执行的；因而，只有已经访问了证书的私钥的请求发送方才可以解密这个消息。一旦消息被签署和加密，服务提供者（Service Provider）的 SOAP 运行时就发送响应给消费应用程序（Consuming Application）。

图 4 —— 服务提供者使用 Web 服务安全性处理响应

消费应用程序处理 Web 服务响应

消费应用程序（Consuming Application）对 Web 服务响应的 Web 服务安全性（WS-Security）的处理与服务提供者（Service provider）对请求执行的处理非常相似。

消费应用程序（Consuming Application）接收到 Web 服务响应，基于最初的 HTTP 会话，响应定向到 SOAP 处理引擎（SOAP 运行时）。在响应中传送的消息数据和共享密钥是加密的。因此，最初的步骤是检索与对应的请求相关联的证书的私钥，以便使用非对称算法来解密共享密钥。通过公开的共享密钥，就可以使用对称算法来解密消息数据。在整个消息公开以后，就可以访问 SOAP 报头中传送的 X.509 证书，以便检索它的公钥。响应消息的数字签名是使用服务提供者（Service Provider）的公钥来执行的。在签名成功确认之后，消费应用程序（Consuming Application）的 SOAP 运行时不仅确认消息的完整性，而且还确保服务提供者（Service Provider）确实对消息进行了签名。这个过程也验证了消息的来源/发送方，因为只有拥有这个证书的发送方才可以访问用于对消息签名的密钥。一旦消息被解密并且确认了签名，SOAP 运行时就将响应发送给消费应用程序（Consuming Application）。

图 5 —— 消费应用程序使用 Web 服务安全性处理响应

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

总结

正如所论述的，Web 服务安全性（WS-Security）非常复杂，并且可以用在很多不同的场景中。上面描述的例子涵盖了今天客户已经实现的很多方面。客户已经在 WebSphere Application Server 平台上实现了这个场景的部分或全部，这取决于他们现有的安全性策略、安全性基础设施或业务需求。这方面的内容将在本文的第 2 部分中进行讨论。

好消息是，WebSphere Application Server 对 Web 服务安全性（WS-Security）的支持是通过声明性的模型进行的。因而，一旦您开发并测试了您的 Web 服务实现，在部署阶段就很容易完成 Web 服务安全性（WS-Security）特征的启用。结果，XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）的复杂性就与作为 IT 架构师或 IT 专家的您关系不大了。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/library/ws-best11/index.html]英文原文[/URL].

参与论坛中关于本文的讨论。（您可以点击本文顶部或底部的讨论来访问论坛。）

查阅整个 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best/index.html]最佳实践专栏系列[/URL]。

WebSphere Studio Application Developer 的实验室训练：使用 WS-Security 保护 Web 服务。

获得这个关于 [URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp?cv_doc_id=85098]保护 Web 服务互操作性[/URL]的教程（ developerWorks，2004 年 2 月）。

Web 服务互操作性（Web Services Interoperability，WS-I）初始工作组草案： [URL=http://www.ws-i.org/Profiles/BasicSecurity/2004-02/SecurityScenarios-0.15-WGD.pdf]Basic Security Profile Scenarios[/URL]。

关于 Web 服务安全性的信息： [URL=http://www.ibm.com/developerworks/webservices/library/ws-secure/]WS-Security[/URL]。

XML 加密语法和处理： [URL=http://www.w3.org/TR/xmlenc-core/]W3C 规范[/URL]。

XML 签名语法和处理： [URL=http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/]W3C 规范[/URL]。

在 [URL=http://publib.boulder.ibm.com/infocenter/wasinfo/topic/com.ibm.websphere.zseries.doc/info/zseries/ae/twbs_secure.html]WebSphere InfoCenter[/URL]上可以找到更多关于 WebSphere Application Server 对 Web 服务安全性支持的信息。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best11/index.html#main]回页首[/URL]

关于作者

[B][/B]
[B][/B]
[B][/B] Holt Adams 目前是支持 IBM jStart 计划的资深咨询 IT 架构师，他与客户和业务合作伙伴一起采用像 Web 服务和 Rich Internet Application 技术这样的新兴技术。他于 1982 年从 University of Tennessee 获得电子工程学位，毕业后加入 IBM 位于北卡罗来纳州的 Research Triangle Park。Holt 具有开发通信和网络产品的软件和硬件的、移动和无线解决方案的技术销售以及基于 Internet 的解决方案的体系结构和集成等方面的经验。在过去的三年里，他致力于把 Web 服务提升为 IBM 的战略性集成技术，起初是和客户一起进行概念的证明，而最近在为生产环境开发解决方案。您可以通过 [URL=mailto:rhadams@us.ibm.com]rhadams@us.ibm.com[/URL]与 Holt 联系。

实际的解决方案中的 Web 服务安全性（WS-Security）

级别: 初级

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#author]Holt Adams[/URL], 资深咨询 IT 架构师, IBM jStart

2004 年 4 月 01 日

理解利用 Web 服务的面向服务体系结构中的安全性选项使您能够选择最好的安全性技术来满足您对于验证、数据完整性和机密性的需求。这是一篇关于 Web 服务安全性的文章的第二部分，它将介绍如何使用 IBM WebSphere Application Server 来在实际的客户解决方案中利用 Web 服务安全性（WS-Security）的功能。
引言

在 OASIS 标准组织中，参与开发 Web 服务安全性（WS-Security）规范的厂商已经积极地测试了与本文第 1 部分中概述的相类似的互操作性场景（ [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#4]请参阅参考资料[/URL]）。OASIS 工作组最初关注的是可用性和与厂商标准的一致性，并不是广泛的互操作性套件或基准。当消费应用程序（Consuming Application）和服务提供者（Service Provider）都在同一厂商的平台（比如 IBM WebSphere Application Server）上时，第 1 部分中的场景就有望获得成功。尽管仍然需要做一些工作来实现不同厂商的平台之间的互操作性，但是通过非正式的 OASIS 测试这方面还是取得了一定的进展。

当验证 Web 服务事务中的一方时，通常需要强制执行公司的安全性策略。通过使用称作成功验证结果的用户身份，应用程序服务器（比如 WebSphere Application Server）可以执行授权来确保正确地控制访问应用程序的资源，例如，Web 服务。考虑第 1 部分中的场景，在通过成功确认数字签名来验证完参与者之后，X.509 证书中提供的身份（专有名称）可以用于 WebSphere Application Server J2EE 安全性模型中的授权。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#main]回页首[/URL]

WebSphere Application Server 对 Web 服务安全性（WS-Security）的支持

正如 Web 服务安全性（WS-Security）规范草案（适用于 2003 年年底发行的 WebSphere Application Server V5.02）所概述的，WebSphere Application Server V5.02 支持 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）。Web 服务安全性（WS-Security）规范处于 OASIS 标准组织内部最终批准的过程中。WebSphere Application Server 将采纳批准的规范中的任何更改。WebSphere Appplication Server 的 Web 服务安全性（WS-Security）功能通过声明性的模型使得可以在部署 Web 服务的实现时启用这些功能。

为了在 WebSphere Application Server 中利用 Web 服务安全性（WS-Security），您实际上不必启用 WebSphere Application Server 的 J2EE Security。您必须加以权衡的是，如果没有 WebSphere Application Server Security，您将不能在执行的线程中设置安全性上下文，或利用 WebSphere Application Server 对 Web 服务或它们的操作进行粗粒度或或细粒度的授权。

WebSphere Application Server 能够支持在第 1 部分中概述的场景。这个场景的一个重要方面是，对于支持大量客户的服务提供者（Service Provider），几乎不需要管理任务。在它本身和消费应用程序（Consuming Application）之间使用 Web 服务安全性（WS-Security）惟一的管理前提就是服务提供者（Service Provider）的本地 keystore 具有认证机构（Certification Authority）（它签发消费应用程序的证书）的根证书。

想要获得关于 WebSphere Application Server 对 WS-Security 支持的全部信息，请参阅本文的 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#4]参考资料[/URL]部分所提供的相关链接。下面将概述 WebSphere Application Server 对 Web 服务安全性（WS-Security）的支持，它适用于在这一部分中介绍的客户场景。

WebSphere Application Server 对 XML 数字签名（XML Digital Signature）的支持如下：

Web 服务请求消息可能包含下列由 WebSphere Application Server 签署的元素：
SOAP 头中的安全性令牌（Security Token）（UsernameToken、基于 XML 的令牌）
SOAP 头中的时间戳（TimeStamp）
SOAP 信封中的主体
Web 服务响应消息可能包含下列由 WebSphere Application Server 签署的元素：
SOAP 头中的时间戳（TimeStamp）
SOAP 信封中的主体
WebSphere Application Server 对 XML 加密（XML Encryption）的支持如下：

Web 服务请求消息可能包含下列由 WebSphere Application Server 签署的元素：
SOAP 头中的安全性令牌（Security Token）（只有 UsernameToken）
SOAP 信封中的主体
Web 服务响应消息可能包含下列由 WebSphere Application Server 签署的元素：
SOAP 信封中的主体
WebSphere Application Server V5.02 和 V5.1 目前支持下面列出的各种 WS-Security 算法：

摘要方法（Digest Method）

[URL=http://www.w3.org/2000/09/xmldsig#sha1]SHA-1[/URL]
签名方法（Signature Method）

[URL=http://www.w3.org/2000/09/xmldsig#rsa-sha1]PKCS1（RSA-SHA1）[/URL]
[URL=http://www.w3.org/2000/09/xmldsig#dsa-sha1]DSA[/URL]
密钥加密方法（Key Encryption Method）

[URL=http://www.w3.org/2001/04/xmlenc#rsa-1_5]RSA Version 1.5[/URL]
[URL=http://www.w3.org/2001/04/xmlenc#kw-tripledes]CMS Triple DES Key Wrap[/URL]
加密方法（Encryption Method）

[URL=http://www.w3.org/2001/04/xmlenc#tripledes-cbc]Triple DES[/URL]

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#main]回页首[/URL]

客户 Web 服务安全性（WS-Security）场景

虽然现在 OASIS 还没有正式批准 Web 服务安全性（WS-Security）规范，但是客户仍然可以利用概念证明的能力或试验解决方案来获得第一手经验，并了解它对客户解决方案性能的潜在影响。下面是现实世界中客户实际使用 Web 服务安全性（WS-Security）的场景。

使用企业身份凭证的企业到企业（Business-to-business）集成

双方都有更好地集成他们的应用程序以便为面对客户和雇员的流程改善整个生命周期的业务需求。双方之间的安全性模型都依赖于消费应用程序（Consuming Application）一方的共享企业身份凭证和双方的 X.509 证书。此时，业务共同的安全性策略声明，双方之间交换的所有机密信息都使用每个企业的边界节点之间的 HTTPS 进行保护。对于每个 Web 服务请求，SOAP 消息的主体都包含 Web 服务操作和相关联的消息部分（它是使用 X.509 证书来进行数字签名的）。签署的的消息的部分之一包括消费应用程序（Consuming Application）的企业身份和密码。服务提供者（Service Provider）使用凭证来执行授权，以便控制对后端业务功能的访问。

服务提供者（Service Provider）之所以使用这个方法，是因为授权逻辑驻留在后端遗留系统中。这种解决方案只是通过 WebSphere Application Server 的前端（它将此方的业务功能作为 Web 服务公开）提供了粗粒度的授权。

每一方都将另一方的 X.509 证书导入到它们的 keystore 中，因此，如果请求或响应不是用它们的 keystore 中已知的证书签名的，这个消息就将被拒绝。一旦消费应用程序（Consuming Application）被验证并且消息的完整性被确认，请求就传送给 Web 服务的实现。

图 1 —— 使用企业身份凭证的 B2B

使用个体凭证的企业应用程序集成

一个客户有多条需要访问遗留系统的业务线。业务需求是，在完全不同的系统之上提供内部的应用程序来访问遗留系统中的企业数据库。次要的目标是，为外部的业务合作伙伴提供同一遗留系统的访问权。每个需要访问数据的用户在在共同的 LDAP 注册中心中都有现存的个体凭证——他的/或她的用户 ID 和密码。用户由消费应用程序（Consuming Application）验证，他们的身份使用 WS-Security UsernameToken安全令牌在 Web 服务请求中传送。安全性令牌和 SOAP 消息体的数字签名使用的是与消费应用程序（Consuming Application）相关联的 X.509 证书。一旦确认签名，消费应用程序（Consuming Application）就被验证了。

在服务提供者（Service Provider）上，设置 WebSphere Application Server 验证使用在 UsernameToken 中传送的身份作为断言的身份，它已经由消费应用程序（Consuming Application）验证。当处理请求时，WebSphere Application Server 将安全性上下文中的身份用于执行的线程。这就使得 WebSphere Application Server 能够提供对 Web 服务资源的细粒度授权。

这个解决方案使用了 WebSphere Application Server 的 WS-Security TimeStamp 元素，并且对这个元素进行了数字签名以防重播攻击。

由于希望这个解决方案支持大量的消费应用程序（Consuming Applications），所以将服务提供者（Service Provider）的管理员的任务减到最少也是一个需求。为了满足这个需求，设置 Web 服务安全性（WS-Security）来提供消费应用程序（Consuming Application）的 X.509 证书作为 Web 服务请求中的二进制安全性令牌。

业务需求就是保护解决方案，使其不依赖于网络传输。解决方案的体系结构包括使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）来满足验证、数据完整性和数据机密性的需求。然而，取决于 XML 加密（XML Encryption）的开销，HTTPS 可以提供数据机密性。这种选择需要加以权衡的是，仅仅在两个网络节点之间提供安全性（一般通过 Internet），而不适用于其他的网络传输。

图 2 —— 使用个体凭证的 EAI

联合身份

一组业务合作伙伴有这样的需求，就是使他们的雇员能够从自己不同的企业访问应用程序。他们的目标是改善他们的流程，允许每个合作伙伴向他们的雇员提供一组统一的服务，这组服务利用了其他合作伙伴的业务功能。例如，业务合作伙伴通常在他们销售周期中为代理集成供应商所使用的信息。尽管业务合作伙伴可能有自定义的 Web 页，但是代理必须离开这个集成的 Web 环境，“跳”到特定的供应商 Web 页去检索所需的信息。业务伙伴的 Web 站点和供应商的 Web 站点之间的跳跃带来了很多的难题，包括安全性问题、内容集成的困难、以及记住众多的用户名、密码和各个供应商的 Web 站点地址所造成的混乱。

主要的业务伙伴在与它的伙伴的关系中具有优势，它使用安全性断言标记语言（Security Assertion Markup Language，SAML）控制对它的 Web 资源（HTML、Servlet、JSP）的访问。结果，他们的需求之一就是利用 SAML 断言控制对他们的 Web 服务的访问。

这些合作伙伴的解决方案包括联合的身分（Federated Identity）模型，在这个模型中，消费应用程序（Consuming Application）验证它的本地用户并使 Web 服务请求断言雇员的身份。正如在前面的客户场景中展示的，服务提供者（Service Provider）依赖于消费应用程序（Consuming Application）去验证用户，但是在这种情况下，每个合作伙伴都有一个不同的安全域。因而，当处理 Web 服务请求时，提供者需要将断言的身份映射到对于它的安全域有效的凭证。这个模型需要任何双方之间具有信任关系。通过使用 SSL 和 X.509 证书，相互验证实现了信任。

合作伙伴的主要目的之一就是不公开用户所在的安全域的用户证书。为了达到这个目的，合作就映射到他们的用户身份的公共假名（common pseudonym）达成一致意见。一个人的社会保障号码（Social Security Number）就是假名的好例子；然而，考虑到法律因素，它不是最好的选择。

Web 服务安全性（WS-Security）可以对 SOAP 头中传送的作为基于 XML 安全性令牌的 SAML 断言进行数字签名，并且签署 SOAP 消息的主体。这提供了验证消费应用程序（Consumer Application）和确保消息完整性的功能。对于这个解决方案，加密使用 HTTPS 的网络连接提供了消息的机密性。

通过使用在 SAML 断言中提供的用户身份作为假名，服务提供者（Service Provider）将假名映射到在它的安全域内有效的本地用户身份。因为业务功能包括授权逻辑，所以在调用 Web 服务实现时，用户身份作为一个 HTTP 头参数在服务提供者（Service Provider）的环境中传送。结果，基于数字签名的成功，WebSphere Application Server 只提供粗粒度的授权。

图 3 —— 使用 SAML 的联合身份

这个解决方案在 WebSphere Application Server 提供对 WS-Security 的支持以前就已经实现了，它使用的是自定义 WS-Security 组件。这个解决方案签署整个 SOAP 消息，并在给消费应用程序（Consuming Application）的响应中提供了一个安全性上下文令牌，以用于后续的请求。这个安全性上下文令牌使性能最优化，类似于传统的 Web 解决方案使用 HTTP cookies 来传送安全性上下文的方式。

WebSphere Application Server V5.02 和 V 5.1 支持传送基于 XML 的令牌（例如，SAML）。然而，必须提供自定义的 JAAS 登录模块（JAAS Login Module）来将令牌中的用户身份合并到 WebSphere Application Server 的安全性上下文中，以便利用 WebSphere Application Server 进行授权。当需要应用程序到应用程序（application-to-application）的安全性而不只是企业边界上网络节点之间的 Internet 安全性时，用户应该考虑 Web 服务安全性（WS-Security）。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#main]回页首[/URL]

总结

因为 Web 服务安全性（WS-Security）将影响总的响应时间以及您的解决方案可以支持的同时发生的请求的数目，所以您决定使用 Web 服务安全性（WS-Security）是非常有道理的，这一点很重要。与使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）提供的解决方案相比，在很多情况下，启用传输持活（KeepAlive）的 HTTPS 提供的解决方案的性能要好得多。然而，HTTPS 究竟为您提供了多好的解决方案实际上取决于您的 Web 服务实现所执行的业务逻辑的总处理时间。如果您的服务是对一个具有良好索引的数据库的简单查询，花费少于 100 毫秒的时间，那么您将看到这两个选择之间巨大的差异。如果您的业务逻辑比较复杂或分布在远程系统之上，并且处理需要花几秒，那么这种选择可能就不会造成那么大的差异。

在比较 Web 服务安全性（WS-Security）和基于传输协议（比如 HTTPS）的可选方案的影响时，您应该保持谨慎。如果只使用包含简单字符串的 Web 服务请求消息，并且服务本身也仅仅是回显（echo）作为响应的消息，那么这样的测试结果可能会导致您得出无意义的结论：使用 Web 服务安全性（WS-Security）的解决方案总是比使用 HTTPS 安全性机制的解决方案的性能低得多。例如，使用中等复杂程度的 XML 结构发送 4K 字节的实际请求消息与使用简单的字符串发送 4K 字节的测试消息相比，SOAP 引擎的处理时间增加了 30%，从而减少了两个安全性机制之间的整体差异。如果您的业务逻辑开始执行，并且必须处理实际的业务信息（这不同于 25 毫秒回显（echo）），那么在执行实际工作时，您就能够切实地理解 Web 服务安全性（WS-Security）给您的解决方案带来的真正影响。

当业务需求证明应用程序端点之间对以任务为中心的数据、具有市场价值的数据或机密的数据的消息完整性的要求是正当的时，由 Web 服务安全性（WS-Security）提供的数字签名功能就是很好的选择，并且可以很容易地在厂商的应用程序服务器（比如 Websphere Application Server）中实现。

XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）都将对您的解决方案产生了影响。如果性能是您超过所有其他需求第一位考虑的因素，那么 HTTPS 就是您最佳的选择。现今，一个常用的实践方法是，使用 XML 数字签名（XML Digital Signatures）验证应用程序和数据完整性，而依赖于 HTTPS 提供机密性。使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）的影响究竟是小还是大，只能通过在您的应用程序环境中使用实际的数据和业务逻辑来启用这个功能，然后测量它们之间的差异，这样才能确定。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#main]回页首[/URL]

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/library/ws-best12/index.html]英文原文[/URL].

参与论坛中关于本文的讨论。（您可以点击本文顶部或底部的讨论来访问论坛。）

查阅整个 [URL=http://www.ibm.com/developerworks/views/webservices/articles.jsp?sort_order=desc&expand=&sort_by=Date&show_abstract=true&view_by=Search&search_by=Best+practices]最佳实践专栏系列[/URL]。

WebSphere Studio Application Developer 的实验室训练：使用 WS-Security 保护 Web 服务。

获得这个关于 [URL=http://www.ibm.com/developerworks/cn/views/webservices/tutorials.jsp?cv_doc_id=85098]保护 Web 服务互操作性[/URL]的教程（ developerWorks，2004 年 2 月）。

关于 Web 服务安全性的信息： [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-secure/]WS-Security[/URL]。

XML 加密语法和处理： [URL=http://www.w3.org/TR/xmlenc-core/]W3C 规范[/URL]。

XML 签名语法和处理： [URL=http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/]W3C 规范[/URL]。

关于安全性断言标记语言（Security Assertion Markup Language，SAML）的信息： [URL=http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security]OASIS 安全性服务技术委员会（OASIS Security Services Technical Committee）[/URL]。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-best12/index.html#main]回页首[/URL]

关于作者


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	531.250ms