Web services 安全实践，第 3 部分
创建自定义的 Policy Set 和 Bindings 为 Web services 配置消息层安全机制
原文链接：https://www.ibm.com/developerworks/cn/webservices/1108_baiy_webservicessecurity3/index.html
柏 越, 吕 双涛, 和 黄 彦军
2011 年 8 月 11 日发布
系列内容：
此内容是该系列的一部分：Web services 安全实践
前言
从文章《第 2 部分：基于 WS-Security 和 Policy Set 为 Web services 配置消息层安全机制》的测试结果中不难看出，我们使用的 Policy Set 除了为 Web services 的交互执行配置了 Authentication 机制外，传输中的 SOAP 消息也被相应地添加了数字签名和加密信息。理论上讲，WS-Security 可以提供更为灵活安全控制，如设定签名的方式、要加密的消息部件等；但由于 WAS 提供的 Policy Set 不容许修改，因而在本节中，我们将实践如何通过自定义 Policy Set，来灵活地部署安全的 Web services。
在 Web services 的安全实践中，非对称的公密钥是最为常见的一种实现机制，本节也将基于非对称的公密钥，来实现 Web services 的安全机制。在文章《第 2 部分：基于 WS-Security 和 Policy Set 为 Web services 配置消息层安全机制》的 2.2 节中，曾对非对称公密钥的使用场景做过简要的介绍，为了帮助读者理解，此处以消息加密的场景为例，对非对称公密钥涉及到的若干术语再一次加以解释，在加密场景中：
- 公钥。公钥通常由若干的消息发送方所持有，用来对发送消息进行加密。
- 私钥。私钥通常只由消息接收方私有，只有匹配的私钥才能对使用相应公钥加密过的消息进行解密。
- 数字证书。在将公钥发布给消息发送方的过程中，为了让消息发送方相信该公钥的来源，通常会将公钥以数字证书的形式发送给 CA 进行认证。
- CA。可以理解为一个第三方的认证中心，为发布的公钥和发布者做出可信性的担保。
创建安全通信中使用的非对称密钥对
在本文中，我们将使用 JDK 所提供的命令行工具（读者也可以采用其他工具）为通信双方生成公钥、私钥及其数字证书。首先，读者可以打开 windows 命令行，并在命令行中打开 WebSphere 的 JDK 所在目录，输入并运行清单 1 中的代码：
清单 1 创建服务端密钥对的命令
| 1 2 3 |
|
如图 1 所示，本文使用 JDK 提供的 keytool 工具创建了一个名为“ServerKeys”的密钥对（公钥 + 私钥），并将其密码设置为“1q2w3e”；此外，我们将该密钥对打包为一个名为“ServerKeysStore”的 KeyStore，并将其密码设置为“q1w2e3”；最后，keytool 会为生成的公钥加上签名，用于向使用该公钥的客户端，证明其来自于签名所属的服务端。
图 1. 创建服务端密钥对
之后 ，我们需要将密钥对中的公钥导出，以将其发布给待通信的客户端。持有该公钥的客户端便可以使用它将消息加密，从而只有持有对应私钥的服务端才能解密并理解该消息的具体内
容。同样是在该命令行中，我们输入清单 2 中的代码：
清单 2 导出服务端公钥证书的命令
| 1 2 3 |
|
如图 2 所示，我们使用刚创建的 KeyStore 的密码，从密钥对 ServerKeys 中抽取了公钥，并将签名后的公钥以 X509 证书的格式保存在了本地文件 D:\paper\server.cert 中。
图 2. 导出服务端公钥证书
接下来，我们还需要创建属于客户端的密钥对，在 KeyTool 的命令行中输入清单 3 中的代码：
清单 3 创建客户端密钥对的命令
| 1 2 3 |
|
如图 3 所示，我们为客户端建立了名为 ClientKeys 的密钥对，并将其存储在名为 ClientKeysStore 的 KeyStore 中，并为其二者设置了相应的密码；另外，这里也为客户端的公钥进行了签名，为了与服务端相区别，此处使用"cn=client,O=MBI,C=US"作为签名的组织信息。
图 3. 创建客户端密钥对
相应地，为了与客户端安全通信，我们还需要将签名过的客户端公钥导入到服务端，从而服务端就可以为响应消息进行加密，而只有持有对应私钥的客户端才可以解密并使用该响应消息，我们在 KeyTool 命令行中输入清单 4 中的代码：
清单 4 导出客户端公钥证书的命令
| 1 2 3 |
|
如图 4 所示，我们使用客户端 KeyStore 的密码从 ClientKeysStore.jks 中抽取了密钥对 ClientKeys 中的公钥，同样以 X509 证书的格式其导入到了本地文件 D:\paper\client.cert。
图 4. 导出客户端公钥证书
在此之后，我们还需要将导出的客户端公钥证书导入到服务端，在 KeyTool 命令行中输入清单 5 中的命令，图 5 显示了该命令的执行结果。
清单 5 将客户端公钥导入服务端 KeyStore 的命令
| 1 2 3 |
|
图 5. 将客户端公钥导入服务端 KeyStore
同样地，我们还需要使用清单 6 中的命令，将服务端公钥证书导入到客户端，图 6 显示了该命令的执行结果。
清单 6 将服务端公钥导入客户端 KeyStore 的命令
| 1 2 3 |
|
图 6. 将服务端公钥导入客户端 KeyStore
至此，我们就完成了所有关于服务安全通信中所需密钥对的创建工作。在下文中，我们需要使用这些密钥对来配置安全策略的 Bindings，所以我们要将其复制到 WAS runtime 的配置目录中，以笔者的环境为例，需将 ServerKeysStore.jks 和 ClientKeysStore.jks 复制到下述目录中 D:\IBM\SDP8\runtimes\base_v7_stub\profiles\AppSrv01\config\cells\localhostNode01Cell。
创建自定义的策略集（Policy Set）
如前文所述，WAS 随产品附带了若干可直接应用于生产环境的 Policy Set，我们可以通过复制这些 Policy Set，并根据我们的需求对其进行修改，以简化自定义 Policy Set 的创建过程。在本文中，我们将选用 WAS 提供的“Username WSSecurity default”作为 Policy Set 模板。
如图 7 所示，在 WAS 控制台中打开“服务 -> 策略集 -> 应用程序策略集 ->Username WSSecurity default”，可以查看该 Policy Set 的具体情况：该策略集主要由 WS-Addressing 和 WS-Scurity 两个 Policy 组成，其中的消息认证是使用 Username Token 来实现，消息的完整性是通过为消息体、时间戳和 Username Token 添加数字签名来实现的，而消息的保密性是通过对消息体、签名和 Username Token 进行加密来实现的。
图 7. WAS 提供的缺省策略集 Username WSSecurity default
但因为 RAD 也不支持 Policy Set 的编辑操作，所以我们将在 WAS 中复制该 Policy Set，并对该副本进行相应的修改。如图 8 所示，还是在 WAS 控制台中，打开“服务 -> 策略集 -> 应用程序策略集”，选中策略集“Username WSSecurity default”后，点击顶部操作面板中的“复制”。
图 8. 复制策略集 Username WSSecurity default
如图 9 所示，在副本 Policy Set 的编辑框中，输入 Policy Set 的名称和相应的描述信息，点击“确定”之后，保存对副本的修改操作。在返回应用程序策略集页面后，可以看到我们新创建的 Policy Set，而且它的状态已变为“可编辑”。
图 9. 编辑策略集副本的基本信息
正如前文所述，RAD 也并不能对 Policy Set 进行编辑，因而我们需要将复制好的 Policy Set 从 WAS 中导出，以便之后通过 RAD 将其应用于 Web services 的服务端和客户端。如图 10 所示，选中上文生成的 EchoPolicySet 后点击“导出”，之后将导出的 EchoPolicySet.zip 保存在本地。
图 10. 导出策略集副本
创建自定义的服务端 Bindings
与前文相似，我们以 WAS 提供的缺省服务端 Bindings 为模板，并对其进行复制修改，以简化自定义 Bindings 的创建过程。在 WAS 控制台中，打开“服务 -> 策略集 -> 常规提供程序策略集绑定”，勾选“Provider sample”之后，点击“复制”。如图 11 所示，在绑定副本的编辑页面中输入名称和描述后，点击“确定”保存所做的修改操作。
图 11. 编辑 Bindings 副本的基本信息
与 Policy Set 不同，WAS 提供的绑定文件都是示例级别的，并不能直接应用于生产环境。因此我们必须针对具体的执行环境，对新创建的 Bindings 文件进行修改。首先，打开“EchoServerBindings->WS-Security-> 密钥和证书；在“信任锚”中点击“新建”，如图 12 所示，我们需要在该页面中编辑锚信息，使用绝对路径将其指向上文生成的服务端 KeyStore，并输入 KeyStore 密码的“q1w2e3”后，点击“确定”以保存修改。
图 12. 编辑用于自定义 Bindings 的证书
在为服务端绑定指定了 KeyStore 之后，我们还需要对 EchoServerBindings 做一些具体的配置动作，以指明在处理传输输出消息时，如何进行消息认证、完整性校验和加解密操作。如图 13 所示，针对服务端的输入消息，打开“EchoServerBindings->WS-Security-> 认证和保护”，在“保护令牌”中选择“con_signx509token-> 回调处理程序”。
图 13. 编辑用于服务端输入消息签名的证书
如图 14 所示，在打开的页面中，我们取消默认的证书库，将其设置为“无”，同时换用我们在上文中创建的 KeyStore，并保存对“回调处理程序”和“EchoServerBindings”的修改，从而设置该绑定使用我们创建的服务端 KeyStore 来校验输入消息的完整性。
图 14. 修改服务端输入消息的信任锚库
对于服务端的输出消息，我们同样要设置用于完整性签名的数字证书。打开“EchoServerBindings->WS-Security-> 认证和保护”，在“保护令牌”中选择“gen_signx509token-> 回调处理程序”，在打开的页面中选择“定制密钥库配置”。如图 15 所示，我们需要在打开的页面中配置服务端密钥对的信息。在保存上述修改之后，我们就完成了对服务端绑定中，输出消息完整性签名的设置操作。
图 15. 编辑用于服务端输出消息签名的密钥信息
接下来，我们要为设置关于输入消息解密的相关信息，还是在“认证与保护”页面中，选择“con_encx509token-> 回调处理程序”，在打开的页面中选择“定制密钥库配置”。与图 13 一样，我们需要为该回调函数配置服务端 KeyStore 的信息，用以对输入消息进行解密。
最后，我们还需要配置绑定中关于消息加密的相关信息，打开“gen_encx509token-> 回调处理程序”，在打开的页面中选择“定制密钥库配置”。如图 16 所示，我们需要设置服务端 KeyStore 的信息，同时还要为服务端输出消息指定之前导入的客户端公钥。
图 16. 编辑用于服务端输出消息的加密的密钥信息
至此，我们就完成了关于自定义绑定的创建操作，为了能够使用 RAD 将将 Policy Set 和 Bindings 与 Web services 的服务端和客户端相关联，我们还需要将创建好的 Bindings 文件导出。在“常规提供程序策略集绑定”中，选中“EchoServerBindings”后点击“导出”，在打开的页面中下载文件“EchoServerBindings.zip”。
使用 RAD 为 Web services 的服务端关联 Policy Set
在上文中，我们创建了自定义的 Policy Set 和 Bindings 文件：其中，Policy Set 主要用于定义 Web services 的 QoS 信息，其内容与具体的实现环境无关；而 Bindings 主要用于实现 Policy Set 与 Web services 的关联操作。
在本节中，我们要使用 RAD 来为 Web services 配置自定义的 Policy Set 和 Bindings 文件，为此，我们首先需要将上文导出的 zip 文件导入 RAD 中。如图 17 所示，读者可以打开“File->Import->WebShpere Policy Sets”来启动导入向导，并在其中选择在上文生成的 EchoPolicySet.zip 文件后，点击 Finish 保存。
图 17. 使用 RAD 导入自定义的 Policy Set
同样地，如图 18 所示，我们可以打开“File->Import->WebSphere General Bindings”以启动 Bindings 导入向导，并在对话框中选择上文生成的 EchoServerBindings.zip 文件，点击 Finish 保存。
图 18. 使用 RAD 导入自定义的 Bindings
之后，我们需要打开项目 WS_Security_Service-> 选择 Services-> 右键选择 {http://com/ibm/was/wassample/sei/echo/}EchoService-> 选择 Manage Policy Set Attachement-> 点击 Edit。如图 19 所示，在 Policy Set and Binding 对话框中，我们可以选择上文中导入的自定义文件。在点击 OK 之后，可以选择 Finish 保存退出。
图 19. 为 Web services 服务端配置自定义的 Policy Set 和 Bindings
至此，我们就完成了服务端 Policy Set & Bindings 的配置工作，为了使配置生效，读者可以重新启动 WAS，或者将服务端项目“WS_Security_Service”从 WAS 中移除后后，重新添加一次。如果用户在 WAS 配置中设置了“Run server with resources on Server”，则可以在 WAS 控制台中，看到如图 20 所示的配置结果。
图 20. 在 WAS 中查看自定义 Policy Set 和 Bindings 的配置结果
使用 RAD 为 Web services 客户端关联 Policy Set
在上文中，我们使用 WAS 创建了自定义的 Policy Set 和自定义的服务端 Bindings，然后使用 RAD 实现了与 Web services 服务端的关联。本节我们将使用 RAD 提供的工具来创建自定义的客户端 Bindings，并使用它将 Web services 的客户端与上文创建的 Policy Set 进行关联。
首先，打开客户端项目 WS_Security_Client-> 打开 Services-> 打开 Client-> 右键选择“{http://com/ibm/was/wassample/sei/echo}EchoService”-> 点击“Manage Policy Set Attachement...”-> 点击“Next”打开客户端 Policy Set 的管理界面。如图 21 所示，点击“Add”按钮为客户端配置一套新的 Policy Set 和 Bindings。
图 21. 为 Web services 客户端配置自定义的 Policy Set 和 Bindings
我们令客户端的 Policy Set 与服务端保持一致，选择自定义的“EchoPolicySet”；对于 Bindings，我们在其输入框中输入一个自定义的名称“EchoClientBindings”。如图 22 所示，新的 Bindings 会出现在 Bindings Configuration 面板中，我们选中其中的“WSSecurity”后，点击按钮“Configure”。
图 22. 使用 RAD 创建自定义的客户端 Bindings
在新启动的 tooling 面板中可以看到，我们需要从 Digital Signature、XML Encryption 和 Authentication 三个方面对自定义的 Bindings 进行配置。我们先从 Authentication 的配置开始，如图 23 所示，打开 Authentication Configuration 面板之后，我们选择“com.ibm.websphere.wssecurity.callbackhandler.UNTGenerateCallbackHandler”作为登录认证的回调函数；之后点击按钮“Callback Handler Settings”，填入 WAS 服务器的用户名和密码，并勾选“Add Timestamp”和“Add Nonce”两个选项，以此做到与服务端的 Bindings 配置相匹配；最后点击“OK”保存所做的修改。
图 23. 配置自定义 Bindings 中的 Authentication
之后，我们要配置自定义 Bindings 的 Digital Signature，Digital Signature 的配置分为 Outbound Message 和 Inbound Message 两个部分。在转到 Digital Signature 选项卡后，保持默认的设置不变，选择 Outbound Message 的 Callback Handler Settings 按钮。如图 24 所示，在弹出的对话框中，我们要选择 Client 端的 KeyStore，并配置相应的 KeyStore 和 Key 的相关信息，最后点击“OK”保存修改。
图 24. 配置自定义 Bindings 中的输出消息签名
然后，我们选择 Inbound Message 的 Callback Handler Settings 按钮，如图 25 所示，在弹出的对话框中，先取消掉选项 Trust Any Certificate，因为我们要配置自己定义的服务端证书作为签名公钥；之后，选择客户端的 KeyStore，并配置相应的 KeyStore 信息；最后，需要注意的是，我们要从本地选择服务端的公钥证书，并点击 OK 保存修改。
图 25. 配置自定义 Bindings 中的输入消息签名验证
最后，我们来完成自定义 Bindings 的 XML Encryption 配置。如图 26 所示，同样地，在打开 XML Encryption 选项卡后，我们首先点击 Outbound Message 按钮。在弹出的对话框中，首先还是要选择客户端的 KeyStore，并配置 KeyStore 的相关信息；另外，我们要将服务端 Key 的信息添加到最后两个属性中，这样客户端就可以使用服务端公钥对输出信息进行加密。
图 26. 配置自定义 Bindings 中的输出消息加密
Inbound Message 的配置相对简单，我们需要配置的 KeyStore 和 Key 的信息均来自于客户端。如图 27 所示，在打开的对话框中，填写相关的客户端密钥信息，并点击 ok 进行保存。
图 27. 配置自定义 Bindings 中的输入消息解密
验证自定义 Policy Set 及 Bindings 的运行
与前文类似，本文使用已配置好的 TCP/IP Monitor 来检测自定义 Policy Set 及 Bindings 的运行情况。在确保 TCP/IP Monitor 运行的情况下，读者可以打开浏览器，输入 Web services 的访问地址“http://localhost:9080/WS_Security_Client/TestServlet”。
首先，如图 28 所示，在 RAD 的控制台中，打印出了服务端执行的响应结果，从而证明我们已经成功调用的了 Web services。
图 28. 控制台中显示的 Web services 调用结果
此外，如图 29 所示，在 TCP/IP 的视图中，可以看到服务端和客户端的输入输出消息均被添加了相应的签名和加密机制，从而证明我们自定的 Policy Set 和 Bindings 成功的被应用到了客户端和服务端。
图 29. TCP/IP Monitor 中显示的 SOAP 消息
总结
本文的内容紧承 Web services 安全实践系列文章《第 2 部分：基于 WS-Security 和 Policy Set 为 Web services 配置消息层安全机制》，介绍了如何创建自定义的 Policy Set 和 Bindings 为 Web services 提供了消息层安全机制。在讲解的过程中，本文首先介绍了如何使用 KeyTool 创建用于安全通信的密钥对、证书等；之后，本文创建了自定义的 Policy Set 和 Bindings，并分别讲解了如何使用 WAS 7 和 RAD 8 对其进行编辑；最后，本文将自定义的 Policy Set 和 Bindings 应用于 Web services，并通过测试验证本文的实验结果。
在讲解的过程中，本文并没有过分深入到诸如安全证书、加密算法等理论内容中，感兴趣的读者可以自己查阅相关的资料；另外，在创建自定义的 Policy Set 和 Bindings 中，本文并没有对 WAS 提供的默认配置做过多的修改，读者可以根据自己的情况，在 WAS 中对副本 Policy Set 和 Bindings 添加相应的修改，例如选择需要签名和加密的部件（Header、Body 或时间戳）以及不同的证书和加密算法等，以定义更加灵活和复合真实生产环境的的服务安全配置。
扫一扫
603
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
