您希望验证发送到接收者的消息还没有被篡改。任何人都可以阅读该消息中的数据,但是您可以检查内容的完整性。
为此,可以应用 WS-Security 标准来指示消息的哪些位已进行了散列操作。使用此信息来定义应用于消息的策略,以支持对消息进行签名。消息是包含标头信息的信封,可以使用标头信息来告诉接收系统如何对传入消息进行身份验证。
图 6 显示了不同的部分如何联系在一起。
您可以看到密钥的私有和公开部分保存在何处以及保存在哪一个密钥存储库中。您还可以看到使用者和提供者之间的关系。下面对这些角色进行细分:
- 提供者是服务的提供者;在此例中是一个 SOAP 服务。
- 使用者是服务的用户;在此例中是使用该 SOAP 服务的客户端。
客户端是发起者和使用者。WebSphere Message Broker 是提供者和接收者。在为 WebSphere Message Broker 创建绑定配置(本文稍后将介绍此过程)时,将引用标签为 A 和 B 的流。
图 7 显示了该信封的不同部分如何联系在一起,意味着 KeyInfo
字段指向消息中的证书。
在此例中,签名信息指向消息的正文。
图 8 显示了消息正文部分及其对应的 DigestValue
。然后对所有的 SignedInfo
进行了签名以提供 SignatureValue
。
SignedInfo
中的引用标识了将要进行摘要、散列或同时进行摘要和散列操作的内容;在此例中为 myBody
。接收者也使用引用中标识的方法来生成值。接收者计算 DigestValue
,然后将结果与所提供的 DigestValue
做比较以完成验证。
有两个参数用作签名算法的输入:
KeyInfo
CanonicalizationMethod
的八位字节流输出。
规范化(Canonicalization) 是规范化 XML 数据的方法。这意味着规范化的 XML 数据始终提供相同的 DigestValue
。
接收者使用 SignatureMethod
和 KeyInfo
的规范形式来确认 SignatureValue
。如果经过摘要操作的值与生成的值匹配,并且签名值与生成的值匹配,则消息是安全的。在 WebSphere Message Broker 中,此行为是通过策略来定义并通过绑定来应用的。
在能够进行验证之前,还必须验证 KeyInfo
以确保证书是有效的。当消息从发起者流出时,证书就开始流动。证书包含在消息的 BinarySecurityToken
部分中。该部分是 base64 编码。该证书的部分内容也经过了签名,以便 WebSphere Message Broker 能够验证该证书是对 WebSphere Message Broker 可用的信任存储库中包含的正式证书颁发机构或自签名证书。
WebSphere Message Broker 支持一种策略类型,该策略类型用于 WS-Security。
- 使用 WebSphere Message Broker Toolkit 的 Administration 透视图来创建并修改策略:
- Configuration Manager 建立到正在运行的代理的连接。
- 选择运行的代理,然后右键单击并启动 Policy Set Editor。
- 通过选择 Policy Set 然后单击 Add 来创建新的策略,如图 9 所示。
图 9. 创建新策略(此示例中创建了 Policy_2)
下面的示例指导您完成配置 WebSphere Message Broker 以进行签名的过程。在图 10 的面板上忽略 UserName authentication tokens 和 x.509 authentication tokens。这用于用户 ID 和密码身份验证,本文将不介绍这方面。
图 10. 身份验证令牌
- 在左侧的窗格中,打开 Message Level Protection,并选中 Message level protection 和 Require signature confirmation 框(请参见图 11)。
图 11. 消息级别的保护
- 在左侧窗格中选择 Tokens,如图 12 所示。
图 12. 显示发起者和接收者令牌
- 添加两个条目,一个用于发起者引用,一个用于接收者引用,并使用 Add 按钮来对这些引用进行命名。然后选择 Token Type 列,该列提供了下拉列表,您可以从下拉列表中选择 Initiator 或 Recipient。
- 选择 Exclusive canonicalization 以设置将在做出选择时使用的算法,如图 13 所示。
图 13. 选择规范化算法
- 在左侧的窗格中,选择 Message Part Protection(请参见图 14)。
图 14. 消息部分保护
- 创建一个针对 Request 消息的条目,并创建一个针对 Response 消息的条目。然后通过将 Message Body 下的值设置为 Yes,从而选择消息的整个正文部分。如果希望对消息的正文签名,您必须始终以同样的方式设置这些策略选项。如果只希望对消息的部分内容签名,您可以使用 Alias、Qname 和 Xpath 来标识消息的该部分(本文不包括此选项)。
现在您需要设置策略绑定,以确定如何使用此策略。
首先,创建一个新的绑定。
- 创建 Bindings_2,并将 Policy_2 策略与之关联,如图 15 所示。
图 15. 将新的绑定与刚才创建的策略集相关联
- 选择 Message Part Policy,并在 Signature Protection 下创建两个条目,如图 16 所示。
图 16. 签名保护
上面的条目将始终具有与发起者引用相关联的请求和与接收者引用相关联的响应。
入站请求(在图 6 和图 17 中的标签为 A)将消息中的证书传递到 WebSphere Message Broker。由于在绑定的 Certificates 列中设置了值 TrustStore,如图 17 所示,因此将根据 CA 证书来检查消息中的证书。存储在信任存储库中的 CA 的公钥用于验证所传递的证书。如果证书经过成功验证,则使用与信任存储库中的公钥匹配的公钥来验证签名。
对于入站的情况,不需要任何其他条目。
对于出站流(在图 6 和图 17 中的标签为 B),提供者发出的响应是对发起者的应答。如果此应答消息也要进行签名,则您将使用私钥来进行此签名。这是图 17 中的 internal recipient reference。此私钥是从服务器的密钥存储库而不是信任存储库获得的(其设置与信任存储库相同,但是针对密钥存储库执行)。您需要确定服务器密钥存储库中的条目,这是通过指定 DN 和密钥别名来实现的。图 17 显示了如何为密钥信息配置 DN 和别名的示例,其中每个方向分别标记为 A 和 B。
现在您已经设置了绑定,下面需要使用 WebSphere Message Broker 工具的 Bar 文件编辑器,将此绑定与流关联起来。
现在您已经配置好 WebSphere Message Broker 来进行签名!
本文阐述了一些有关对消息进行签名的 WS-Security 概念。您了解了密钥存储库的使用,包括如何使用它们来设置签名。然后您使用了一个在 WebSphere Message Broker 中创建策略和绑定的工作示例,从而完成了设置 WebSphere Message Broker 以允许流签名所需要的步骤。