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）的各种方法以及您应该预料到的性能影响。

一般的 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 证书的私钥来解密消息

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 加密的详细信息。

现实世界中的 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 服务安全性处理响应

总结

正如所论述的，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 专家的您关系不大了。

参考资料

您可以参阅本文在 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.shtml]最佳实践专栏系列[/URL]。

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

获得这个关于 [URL=http://www.ibm.com/developerworks/cn/cnedu.nsf/webservices-onlinecourse-bytitle/E63FA918416F21ADC8256E5100111517?OpenDocument]保护 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 服务安全性支持的信息。

关于作者

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 联系。