使用 WebSphere Studio 构建安全的 Web 服务: 第 1 部分：XML 签名

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Jeffrey Liu (jeffliu@ca.ibm.com), 软件开发人员, IBM 多伦多实验室

2004 年 4 月 01 日

本文向您展示如何使用 WebSphere Studio 和 IBM 密钥管理（IBM Key Management）工具并利用新的 Web 服务安全性规范的两个方面--XML 签名（XML signature）和数字证书（digital certificate）来保护 Web 服务的安全。

引言

世界范围内的企业正在迅速地采用Web 服务，从而引发了对更为全面的 Web 服务架构的需求。互操作性是一个关键的挑战，而 Web服务互操作性组织（Web Services Interoperability organization，WS-I）是这一领域的关键角色。第二个关键的挑战是Web 服务安全性，它涉及很多方面，其中包括身份验证（authentication）、授权（authorization）、完整性（integrity）、机密性（confidentiality）和可靠性（reliability）。保护Web 服务的通用机制包括 J2EE基于角色的安全性和安全套接字层（Secure Socket Layer，SSL）。然而，这些机制并不是设计用来在SOAP 消息层次上进行操作。为了弥补这一缺陷，IBM、微软和 Verisign提出了一个 Web 服务安全性规范并把它提交到 结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，OASIS）进行评估。之后，OASIS把该规范作为工作草案进行发布，并且另外的公司已经加入到创建Web 服务安全性规范的工作中。OASIS 现在已经发布了两个 Web 服务安全性规范：

• Web 服务安全性（WSS）：简单对象访问协议（SOAP）消息安全性（WebServices Security（WSS）：Simple Object Access Protocol（SOAP）Message Security）
• Web 服务安全性（WSS）：用户名令牌概要（ Web Services Security（WSS）：Username Token Profile）

这些规范中的亮点包括通过 XML 签名进行身份验证、通过 XML 加密保证机密性以及通过安全性令牌进行凭证传播这些内容。本文将向您简要地介绍 XML 签名和数字证书。本文还将向您展示如何使用IBM Key Management 工具和 IBM WebSphere Studio Application Developer V5.1（以下简称为 Application Developer）来构建并保护 Web 服务的安全。

回页首

使用 XML 签名来保证 Web 服务安全性

WebSphere Application Server V5.0.2支持在 WSS：SOAP 消息安全性（WSS：SOAP Message Security）规范中定义的关键特征，其中包括 XML 签名。 WSS：SOAP 消息安全性（WSS：SOAP Message Security）规范没有规定任何新的 XML 签名语法或算法，但它是建立在现有的 XML 签名语法和处理（XML Signature Syntax and Processing）标准之上，并且定义了把 XML 签名附加于 SOAP消息的标准格式。XML签名保证它们所引用的数据的完整性，并且确保数据内容不被篡改。XML还可以用于连接安全性令牌（例如：X.509 证书）来验证 SOAP 消息的签署者/发送者的一致性。

XML 签名

XML 签名本质上是附加于 XML 文档的 XML 片断。该 XML 片断功能如此强大的原因在于只能使用原 XML 文档的数据和只有签名者才能使用的密钥来生成该片断。以下步骤将说明 XML 签名的过程：

1. 识别 XML 文档中需要签署的的元素。
2. 对于每个元素，应用一列可选的转换。转换允许可修改的数据从 XML 签名的计算中删掉。考虑一个购买订单场景--图 1 显示了经过不同部门（例如销售部门、配送部门等等）处理的样本购买订单文档：
   图 1. 样本购买订单文档
   
   

   在处理该文档时，每个部门都签署它并把各自的部门 ID 附加到 path 元素。在计算每个部门的 XML 签名之前（在本例中，指在后续部门把他们的部门 ID 附加到 path 元素之时）必须去掉 path 元素，这是因为如果修改了用于计算签名的原始数据将会导致 XML 签名无效。最后转换（如果没有转换则是原始元素的内容）所产生的结果值被用来计算摘要值。

3. 摘要值是用于验证原始元素内容的复杂的校验和。对元素内容的任何改变都将改变摘要值。接收方可以通过重新计算元素的摘要值并把它和接收到的摘要值进行比较来确认该元素的完整性。如果不匹配就表示内容已被修改，因此也不能信任。
4. 图 2 显示一个摘要值的 XML 表示法。SignedInfo 元素封装了摘要值以及与之相关的信息：
   图 2. SignedInfo 元素
   
   虽然使用摘要值保证了 XML文档的完整性，但是它不能防止某些人截取文档、篡改文档、重新计算摘要值以及转发修改了的文档。为了克服这一问题，将计算出一个基于 SignedInfo元素的签名值，并且只有文档的签名者能够生成正确的签名值。
5. 在可以用 SignedInfo元素计算签名值之前，必须先规范化（标准化）该元素。规范化过程访问XML 片断可能拥有的不同文本表示法。例如，给定相同的XML片断，对注释和空格不同的解释方式会导致不同的数据流。即使没有篡改内容，这些偏差也会导致XML 签名无效。
6. 接下来，将使用签名算法来加密规范化过程产生的结果。这包括使用只有签名者才有权使用的密钥。产生的结果是签名值。接收方可以使用签名者的公钥来解密并验证签名值。
7. 签名值和 SignedInfo元素被一起附加到原始 XML 文档。于是就完成了创建 XML签名的过程。
8. 为了验证文档的内容，需要使用发送方的公钥来解密数字签名。解密的结果是作为该文档的校验和的摘要代码。对文档任何细微的改变都将导致摘要代码错误。

数字证书

数字证书类似于电子ID。它标识证书所有者并传递所有者的公共密钥。每个证书都是由认证机构（Certificate Authority，CA）颁发的。下列步骤将说明数字证书的基础。

1. 图3 显示一个服务器在向 CA发送认证请求。认证请求包括如下信息：
   • 服务器的专有名称（distinguished name），它包含服务器的常用名称（commonname）、组织名称（organization name）等等。
   • 服务器的公钥。
   • 服务器的签名。
   
   图 3.认证请求
   
   
2. CA检验请求并验证服务器。如果服务器通过了验证，那么CA就会使用自己的私钥来签署该服务器的公钥并为其颁发一个证书，该证书包含了来自原始认证请求的信息以及CA 的签名：
   图 4. CA 签署并颁发证书
   
   
3. 该服务器现在可以将证书展示给要求验证的客户端。客户端通过确认CA在证书上的签名来检验证书。为达此目的，客户端需要一份CA公钥的副本。因为公钥是在证书中分发的，所以客户端需要一份CA 证书的副本。该 CA 的证书可以通过另一个 CA来发行，在这种情况下，客户端同样需要信任来自另一个CA的证书。最后，客户端将到达一个拥有自签署证书的根CA。
4. 证书可以保存在 keystore（专用密钥数据库）文件中。keystore 文件包含个人证书、签署者证书以及所有者的私钥。个人证书是您分发给其他人的证书；签署者证书是您信任的证书。图 5显示基于样本场景的每个实体所拥有的 keystore：
   图 5. 每个实体所拥有的证书
   
   
5. 图5 所示的机构允许单向验证，也就是说，客户端能够验证服务器，但是反过来不可以。为了建立相互验证，客户端需要从CA 获取证书，并且服务器需要把该 CA的证书添加到它自己的 keystore 中。

回页首

创建证书和keystore

为了通过 XML 签名在 Web 服务和 Web服务客户端之间建立安全的通信通道，您需要为服务器和客户端二者创建数字证书和keystore。这部分将向您展示如何利用 IBM Key Management工具来完成这一工作。

1. 首先，确保正确地设置了命令行环境。使用文本编辑器打开
   <WebSphere Studio Application Developer installation directory>/runtimes/base_v5/bin/setupCmdLine.bat 。头两行代码应该与如下代码类似：

   SET WAS_HOME=<WebSphere Studio Application Developer installation directory>\runtimes\base_v5 SET JAVA_HOME=<WebSphere Studio Application Developer installation directory>\runtimes\base_v5\java

   
   
2. 要运行 IBM Key Management工具，请打开命令提示符并转到
   <Application Developer installation directory>/runtimes/base_v5/bin 文件夹。然后运行 ikeyman.bat 命令。图 6显示了 IBM Key Management 工具：
   图 6. IBM Key Management 工具
   
   
3. 创建服务器的keystore。选择 Key Database File => New.
4. 图 7显示了 new key database file 对话框。确保选取了 JKS作为密钥数据库类型。为文件名输入 server_keystore.jks ，并输入您的文件系统的任意位置。单击 OK。在 password对话框，输入 server123 作为密码，然后单击 OK：
   图 7. 创建服务器的 keystore
   
   
5. 删除所有自动添加到keystore的签名者证书。这些证书中的一部分已经过期，并且如果您不删除它们将会引起问题。单击 Delete来删除所选择的证书。
6. 服务器不会向真正的 CA发送证书请求，而是自己担任 CA 的角色并创建自签署证书来代替。在下拉菜单中选取 Personal Certificates并单击 New Self-Signed：
   图 8. 创建自签署证书
   
   
7. 图 9显示了 Create New Self-signed Certificate 对话框。在此对话框中，输入 echo_ws 作为 Key Label。确保为 Version 选择了 X.509 V3，为 Key Size 选择了 1024。然后输入您的组织名称（organizationname）。单击 OK：
   图 9. Create new self-signed certificate对话框
   
   
8. 把 echo_ws 证书提取到您的文件系统中。您稍后将会把它作为签署者证书导入到客户端的 keystore中。为了使客户端验证 echo_ws 证书，该客户端需要拥有签署了这个证书的 CA的公钥。在本例中，将是服务器，这是因为服务器也担任了CA的角色。这意味着客户端需要导入服务器的证书作为签名者证书。要提取 echo_ws 证书，请单击 Extract Certificate。确保选择 Base64-encoded ASCII data作为数据类型，为证书名称输入 server.arm ，然后输入任意位置，并单击 OK：
   图 10. 提取服务器的证书
   
   
9. 接下来，创建客户端的 keystore文件。选择 Key Database File => New。
10. 选择 JKS作为密钥数据库类型，为文件名输入 client_keystore.jks ，然后输入任意位置并单击 OK。在 password 对话框中，输入 client123 作为密码，然后单击 OK。
11. 再一次，删除所有自动添加到keystore 的签署者证书。
12. 把服务器的证书作为签署者证书导入客户端的keystore。单击 Add，查找 server.arm ，然后单击 OK（参见图11）。系统将会提示您为该证书输入标签。输入 echo_ws 作为标签名称，然后单击 OK：
    图 11. 将服务器的证书添加到客户端的 keystore
    
    
13. 您现在将为客户端创建证书。客户端也将担任CA 的角色并创建自签署证书。在下拉菜单中选取 Personal Certificates并单击 New Self-Signed。在 create newself-signed certificate 对话框，输入 echo_client 作为密钥标签。确保为 Version 选择 X509 V3，为 Keysize 选择 1024。输入您的组织名称并单击 OK。
14. 将 Echo Web 服务客户端证书提取到您的文件系统。您将把它作为签名者证书导入服务器的keystore。单击 Extract Certificate，确保选取 Base64-encoded ASCII data作为数据类型，为证书文件名称输入 client.arm ，然后输入任意位置，并单击 OK。
15. 打开服务器的keystore。选择 Key Database File => Open。
16. 转到 server_keystore.jks 然后单击 OK。系统将提示您输入服务器 keystore的密码。输入 server123 并单击 OK。
17. 把客户端的证书作为签名者证书导入到服务器的keystore。在下拉菜单中选取 Signer Certificates，然后单击 Add，转到 client.arm ，并单击 OK。为标签名称输入 echo_client 并单击 OK。图 12 显示了结果：
图 12. 将客户端的证书添加到服务器的 keystore


18. 您已经成功创建了本教程所需的keystore 和证书。您现在可以关闭 IBM KeyManagement 工具。图 13 总结了您在这部分中已经创建的keystore 和证书：
    图 13. 对本部分所创建的 keystore 和证书的总结
    
    

回页首

构建 Echo Web 服务和 Web 服务客户端

这部分将带您完成通过 Echo Java Bean 来创建 Web 服务和 Web服务客户端的步骤。创建一个名为 Echo.java 并带有如下内容的文件：

package ws; public class Echo { public String echo(String s) { return s; } }

1. 启动WebSphere Studio。
2. 创建 Web 项目。选择 File =>New => Other。
3. 从左侧菜单中选择 Web并从右侧列表中选择 Dynamic Web Project。单击 Next。
4. 图14 显示了 New Web Project 向导。为项目名称输入 EchoService ，然后单击 Finish：
   图 14. New Web Project 向导
   
   
5. 将 Echo JavaBean 导入到该 Web 项目。选择 File => Import。
6. 选择 File system并单击 Next。
7. 找到您创建 Echo.java 的文件夹，并选择它，在 Into folder文本域中输入 EchoService/JavaSource/ws 。然后单击 Finish：
   图 15. 导入 Echo.java
   
   
8. 运行 Web Service Creation向导。选择 File => New => Other。
9. 从左侧菜单中选择 Web services并从右侧列表中选择 Web service。然后单击 Next。
10. 图16 显示了 Web Services Creation 向导。选择 Java bean Web Service作为 Web 服务类型。选取 Generate a proxy、 Test the generated proxy和 Overwrite files without warning复选框。然后单击 Next：
    图 16. Web Services 向导
    
    
11. 使用在 Service Deployment Configuration页面定义的缺省选项并单击 Next。
12. 在 Web Service Java Bean Selection页面，输入 ws.Echo 作为 Java Bean的类名称。然后单击 Finish。

您已经成功地创建了 Echo Web服务和 Web服务客户端。接下来的部分将向您展示如何配置它们以使用XML 签名。

回页首

保护 Echo Web 服务和 Web 服务客户端的安全

由于 WSS: SOAP 消息安全性（WSS: SOAP MessageSecurity）和 WSS: 用户名令牌概要（WSS: Username Token Profile）还没有最后定稿，所以没有在标准的 JSR-109 部署描述符中配置 XML 签名的标准格式。可以通过 JSR-109部署描述符的 IBM 扩展来提供对 XML 签名的支持。Web Services Editor和 Web Services Client Editor为编辑这些部署描述符提供了非常便利的途径。

签署 SOAP 请求

Web Services Client Editor允许您为签署客户端 SOAP 请求指定密钥。

1. 转到 WebSphere Studio工作台的 EchoServiceClient/WebContent/WEB-INF 文件夹，然后双击 webservicesclient.xml来调出 Web Services Client Editor。
2. 单击 Security Extensions选项卡。图 17 显示了 Web Services Client Editor的安全性扩展页面：
   图 17. Web Services Client Editor 的 Security Extensions页面
   
   
3. 展开 Request Sender Configuration => Integrity部分。单击 Add，并选择 body作为 Reference Part，然后单击 OK：
   图18. 完整性
   
   
4. 单击 Port Binding选项卡以调出端口绑定页面。
5. 在 Security Request Sender Binding Configuration => Key Locators部分，单击 Add。 一个密钥定位器（key locator）指定了用于检索密钥的储存库。
6. 图19 显示了 Key locator 对话框。输入所需信息。用 client_keystore.jks文件所在的位置替换 keystore 路径。如果您为客户端keystore 选择您自己的密码来代替 client123 ，那么请在 key store storepass和 Key pass 栏中输入您的密码。然后单击 OK：
   图 19. Key locator对话框
   
   
7. 在 Security Request Sender Binding Configuration => Signing Information部分，单击 Enable。在本例中签署信息确定用于签署输出SOAP 消息的密钥。
8. 图 20 显示了 Signing information对话框。输入所需的信息，然后单击 OK：
   图 20. Signing information对话框
   
   
9. 保存Web Services Client Editor。

验证服务器响应

Web Services Client Editor还允许您确认 SOAP 响应消息的完整性并验证响应的发送方。

1. 在Web Services Client Editor，单击 Security Extensions选项卡。
2. 在 Security Extensions 页面，展开 Response Receiver Configuration => Required Integrity部分。单击 Add，然后选择 body作为 Reference Part，再单击 OK。
3. 单击 Port Binding选项卡。在 Security Response Receiver Binding Configuration => Certificate Store List=> Collection Certificate Store部分，单击 Add。一个包含了一组证书的证书存储器将被用于检验输入的 X.509安全性令牌。
4. 图 21 显示了 Collection certificate store对话框。输入所需的信息，然后单击 OK：
   图 21. Collection certificate store对话框
   
   
5. 在 Security Response Receiver Binding Configuration => Trust Anchor部分，单击 Add。信任锚（trust anchor）指定了一组用于存放来自信任的CA 的证书的 keystore。
6. 图 22 显示了 Trust anchor对话框。输入所需的信息，然后单击 OK：
   图 22. Trust anchor 对话框
   
   
7. 在 Security Response Receiver Binding Configuration => Signing Information部分，单击 Add。本例中签署信息确定了用于检验输入的SOAP 消息的证书。
8. 图 23 显示了 Signing information对话框。输入所需的信息，然后单击 OK：
   图 23. Signing information 对话框
   
   
9. 保存Web Services Client Editor。

签署 SOAP 响应

继续该场景，您将利用 Web Services Editor来指定用于签署服务器 SOAP 响应的密钥。

1. 转到 EchoService/WebContent/WEB-INF 文件夹，然后双击 webservices.xml以调出 Web ServicesEditor。
2. 单击 Security Extensions选项卡。展开 Response Sender Service Configuration Details => Integrity部分。单击 Add，然后选择 body作为 ReferencePart，再单击 OK。
3. 单击 Binding Configurations选项卡。在 Response Sender Binding Configuration Details => Key Locators部分，单击 Add。
4. 图 24 显示了 Key locator对话框。输入所需的信息，然后单击 OK：
   图 24. Key locator 对话框
   
   
5. 在 Response Sender Binding Configuration Details => Signing Information部分，单击 Enable。
6. 图 25 显示了 Signing information对话框。输入所需的信息，然后单击 OK：
   图 25. Signing information对话框
   
   
7. 保存Web Services Editor。

验证客户端请求

Web Services Editor还允许您检验客户端 SOAP请求的完整性并验证请求的发送方。

1. 在Web Services Editor，单击 Security Extensions选项卡。
2. 在Security Extensions 页面，展开 Request Receiver Service Configuration Details => Required Integrity部分。单击 Add，然后选择 body作为 ReferencePart，再单击 OK。
3. 单击 Binding Configurations选项卡。在 Request Receiver Service Configuration Details => Certificate Store List => Collection Certificate Store部分，单击 Add。
4. 图26 显示了 Collection certificate store对话框。输入所需的信息，然后单击 OK：
   图 26. Collection certificate store 对话框
   
   
5. 在 Request Receiver Service Configuration Details => Trust Anchor部分，单击 Add。
6. 图 27 显示了 Trust anchor对话框。输入所需的信息，然后单击 OK：
   图 27. Trust anchor 对话框
   
   
7. 在 Request Receiver Service Configuration Details => Signing Information部分，单击 Add。
8. 图 28 显示了 Signing information对话框。输入所需的信息，然后单击 OK：
   图 28. Signing information 对话框
   
   
9. 保存Web Services Editor。

在对部署描述符的更改生效之前，必须重启 Echo企业应用程序。

1. 打开服务器透视图。单击菜单 Window => Open Perspective => Others。
2. 选择 Server并单击 OK。
3. 在 Servers 视图，右键单击 Echo企业应用程序部署到的服务器=> Restart Project => DefaultEAR。

回页首

测试 Echo Web 服务

在生成样本 JSP 时，他们缺省地使用 Java 2 Standard Edition（J2SE）的方法来实例化客户端存根。J2SE 方法是单独地基于由JAX-RPC定义的程序设计模块。这意味着客户端存根对象不了解在 JSR-109部署描述符中定义的配置，例如：XML签名配置。为了利用部署配置，JSR-109 需要通过 JNDI查找可用的服务接口（Service Interface）实例化客户端存根。因此，您必须修改生成的样本JSP 以使用 JNDI 查找来代替缺省的 J2SE方法。下列步骤将向您展示如何完成这一工作：

1. 转到 EchoServiceClient/WebContent/sample/Echo文件夹，右键单击，然后选择 Result.jsp => Open With => Text Editor。
2. 如图 29所示修改 Result.jsp 。保存并关闭文本编辑器。
   图 29. Result.jsp
   
   
3. 右键单击 TestClient.jsp => Run on Server。
4. 选择Echo Web 服务部署到的服务器，然后单击 Finish。
5. 单击 echo（java.lang.String）方法，在输入文本域输入 Hello World ，然后单击 Invoke。结果将显示在 Result窗格中。详细情况请参阅图 30：
   图 30. 调用 Echo Web 服务
   
   图 31 和 32 显示在 TCP/IP 侦听服务器中捕获的 SOAP请求和响应。客户端和服务器的 XML 签名被分别附加到SOAP 请求头部和 SOAP 响应头部：
   图 31. SOAP 请求
   
   
   图 32. SOAP 响应
   
   

回页首

结束语

本文提供了对XML 签名和数字证书的介绍。本文讨论了如何使用 IBM Key Management工具和WebSphere Studio V5.1 并利用 XML 签名来构建安全的 Web服务。XML签名允许您确认消息的完整性并验证消息的发送方。XML签名是保护您的 Web服务的众多方法中的一种。本系列的其他文章将涉及保护Web 服务的其他机制。

参考资料

• Organization for the Advancement of Structured Information Standards (OASIS)
  
  
  
  
• Web Services Interoperability (WS-I)
  
  
  
  
• Simple Object Access Protocol (SOAP)
  
  
  
  
• Web Service Description Language (WSDL)
  
  
  
  
• Web Services Security：SOAP Message Security
  
  
  
  
• Web Services Security：Username Token Profile
  
  
  
  
• XML Signature Syntax and Processing
  
  
  
  
• Java API for XML-based Remote Procedure Call (JAX-RPC)
  
  
  
  
• Java Specification Request 109 (JSR-109)
  
  
  

关于作者

		Jeffrey Liu 是 IBM 多伦多实验室的 Web Services Tools Team 的一名软件开发人员。您可以通过 jeffliu@ca.ibm.com 与 Jeffrey 联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首