本文共 8165 字,大约阅读时间需要 27 分钟。
设置 Web Services Security (WS-Security) 来对应用程序与 IBM® WebSphere® Message Broker 之间发送和接收的数据进行签名。本文描述基本概念、如何设置环境和如何配置 WebSphere Message Broker 来对数据签名。这里提供的信息与平台和操作系统无关,但是您可以在适当的地方看到特定操作系统的示例。本文结尾处关于术语的部分将帮助阐明本文所描述的概念。
首先,让我们看看与签名有关的一些重要概念的定义:
可以使用工具来设置密钥存储库,例如 WebSphere Message Broker Java™ Runtime Environment (JRE) 组件中的工具 keytool 和 iKeyman。您必须提供有关您在何处创建了密钥存储库的信息,这样 WebSphere Message Broker 才能使用它们来完成签名过程。
您还需要定义 WebSphere Message Broker 策略,以告诉系统是否正在使用签名或加密,以及哪一端在执行签名或加密。然后将该策略与某个绑定相关联,此绑定将该策略绑定到 WebSphere Message Broker 的流。该绑定从 WS-Security 签名的角度告诉 WebSphere Message Broker 如何处理传入和传出消息。
如上所述,密钥存储库是用于存储证书和密钥条目的存储库。虽然似乎有点混淆,但是存在两种类型的密钥存储库,它们仅在使用方式方面存在区别:
可以定义密钥存储库和信任存储库以应用于 WebSphere Message Broker 或应用于 WebSphere Message Broker 上的某个执行组。有关这方面的更多详细信息,请访问 WebSphere Message Broker 信息中心(请参阅以获取链接)。稍后您可以在本文中看到示例。
密钥存储库包含以下条目:
WebSphere Message Broker 仅支持将 Java 密钥存储库(Java keystore,JKS)用于密钥存储库和信任存储库。
设置密钥存储库的最快方法是创建您自己的证书,称为自签名证书。您最终将获得包含公开证书和私钥的密钥存储库。要设置信任存储库,您需要导出公开证书并将其导入新的信任存储库。信任存储库通常仅包含公开证书。
当 WebSphere Message Broker 接收到消息时,除非设置了选项 Trustany,否则将根据信任存储库中的证书来验证消息中的证书。您可以在图 17 中看到此选项,其中将信任设置为 TrustStore。
WebSphere Message Broker 提供的 keytool 实用工具或 iKeyman 实用工具对密钥存储库进行管理。
下面使用 iKeyman V7.0.3.28 来逐步地创建一个自签名的证书以便分发到服务器。
Alias name: mikespublickeyCreation date: 06-Mar-2008Entry type: trustedCertEntry Owner: CN=KDHMT99.hursley.ibm.com, C=GBIssuer: CN=KDHMT99.hursley.ibm.com, C=GBSerial number: 47cfeaf6Valid from: 06/03/08 13:00 until: 06/03/09 13:00Certificate fingerprints:MD5: 36:52:BF:C0:E4:67:6F:E2:3F:1E:00:91:5D:0B:8A:54SHA1: F4:50:21:6B:16:60:A3:3B:ED:56:59:AE:03:1A:E6:5D:52:DC:57:66 |
mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystoreFile -v [Location of server keystore] mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystoreType -v JKSmqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystorePass -v testexecutiongroupname Keystore::password |
有关 mqsichangeproperties 命令的更多信息,请访问 WebSphere Message Broker 信息中心(请参阅)。
mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n truststoreFile -v [Location of server truststore] mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n truststoreType -v JKSmqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n truststorePass -v testexecutiongroupname Truststore::password |
在为 WebSphere Message Broker 定义密钥存储库以后,您可以使用 mqsireportproperties 命令来查看名为 test_brk 的 WebSphere Message Broker 和名为 testexecutiongroupname 的执行组的设置(请参见清单 4)。)
mqsireportproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager –r |
如果还没有为执行组设置属性的话,使用 mqsichangeproperties 命令来设置的属性将应用于整个 WebSphere Message Broker。mqsireportproperties test_brk -o BrokerRegistry –a 为您提供了用于代理范围的设置的命令,如清单 5 所示。
BrokerRegistry='' uuid='BrokerRegistry'brokerKeystoreType='JKS'brokerKeystoreFile=''brokerKeystorePass='brokerKeystore::password'brokerTruststoreType='JKS'brokerTruststoreFile=''brokerTruststorePass='brokerTruststore::password'httpConnectorPortRange=''httpsConnectorPortRange='' |
下面您将通过为其提供信任存储库密码来更新 WebSphere Message Broker;请注意,必须停止 WebSphere Message Broker 才能完成此操作。清单 6 显示了该命令的情况。
mqsisetdbparms test_brk -n brokerTruststore::password -u temp -p pa55word |
此时,您已经设置并定义了密钥存储库,并且您已经准备好了解有关签名的更多信息了。
您希望验证发送到接收者的消息还没有被篡改。任何人都可以阅读该消息中的数据,但是您可以检查内容的完整性。
为此,可以应用 WS-Security 标准来指示消息的哪些位已进行了散列操作。使用此信息来定义应用于消息的策略,以支持对消息进行签名。消息是包含标头信息的信封,可以使用标头信息来告诉接收系统如何对传入消息进行身份验证。
图 6 显示了不同的部分如何联系在一起。
您可以看到密钥的私有和公开部分保存在何处以及保存在哪一个密钥存储库中。您还可以看到使用者和提供者之间的关系。下面对这些角色进行细分:
客户端是发起者和使用者。WebSphere Message Broker 是提供者和接收者。在为 WebSphere Message Broker 创建绑定配置(本文稍后将介绍此过程)时,将引用标签为 A 和 B 的流。
图 7 显示了该信封的不同部分如何联系在一起,意味着 KeyInfo 字段指向消息中的证书。
在此例中,签名信息指向消息的正文。
图 8 显示了消息正文部分及其对应的 DigestValue。然后对所有的 SignedInfo 进行了签名以提供 SignatureValue。
SignedInfo 中的引用标识了将要进行摘要、散列或同时进行摘要和散列操作的内容;在此例中为 myBody。接收者也使用引用中标识的方法来生成值。接收者计算 DigestValue,然后将结果与所提供的 DigestValue 做比较以完成验证。
有两个参数用作签名算法的输入:
规范化(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 以进行签名的过程。在图 10 的面板上忽略 UserName authentication tokens 和 x.509 authentication tokens。这用于用户 ID 和密码身份验证,本文将不介绍这方面。
现在您需要设置策略绑定,以确定如何使用此策略。
首先,创建一个新的绑定。
上面的条目将始终具有与发起者引用相关联的请求和与接收者引用相关联的响应。
入站请求(在 和图 17 中的标签为 A)将消息中的证书传递到 WebSphere Message Broker。由于在绑定的 Certificates 列中设置了值 TrustStore,如图 17 所示,因此将根据 CA 证书来检查消息中的证书。存储在信任存储库中的 CA 的公钥用于验证所传递的证书。如果证书经过成功验证,则使用与信任存储库中的公钥匹配的公钥来验证签名。
对于入站的情况,不需要任何其他条目。
对于出站流(在 和图 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 以允许流签名所需要的步骤。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-412084/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-412084/