首先,让我们看看与签名有关的一些重要概念的定义:
- 签名提供消息完整性和签名者身份验证。
- 消息完整性确保消息未被修改。
- 签名者身份验证(也称为数字签名)确保消息发送者的身份是有效的。
- 密钥用于对消息签名。
- 证书用于验证消息的内容。
- 密钥存储库保存这些证书和密钥。
可以使用工具来设置密钥存储库,例如 WebSphere Message Broker Java™ Runtime Environment (JRE) 组件中的工具 keytool 和 iKeyman。您必须提供有关您在何处创建了密钥存储库的信息,这样 WebSphere Message Broker 才能使用它们来完成签名过程。
您还需要定义 WebSphere Message Broker 策略,以告诉系统是否正在使用签名或加密,以及哪一端在执行签名或加密。然后将该策略与某个绑定相关联,此绑定将该策略绑定到 WebSphere Message Broker 的流。该绑定从 WS-Security 签名的角度告诉 WebSphere Message Broker 如何处理传入和传出消息。
如上所述,密钥存储库是用于存储证书和密钥条目的存储库。虽然似乎有点混淆,但是存在两种类型的密钥存储库,它们仅在使用方式方面存在区别:
- 密钥存储库:可以在密钥存储库中放置所有的私钥和公钥证书 (PKC)。
- 信任存储库:可以在信任存储库中放置所有受信任的根证书颁发机构(certificate authority,CA)证书。这些证书用于建立任何入站 PKC 的信任关系。信任存储库通常仅包含公钥。
可以定义密钥存储库和信任存储库以应用于 WebSphere Message Broker 或应用于 WebSphere Message Broker 上的某个执行组。有关这方面的更多详细信息,请访问 WebSphere Message Broker 信息中心(请参阅参考资料以获取链接)。稍后您可以在本文中看到示例。
密钥存储库包含以下条目:
- 密钥存储库——密钥条目:这种类型的密钥存储库条目包含非常敏感的加密密钥信息,该信息以受保护的格式存储以防止未经授权的访问。通常,存储在此类条目中的密钥是对对应的公钥进行身份验证的证书链所附带的私钥。
- 信任存储库——受信任的证书条目:这种类型的条目包含单个属于另一方的 PKC。将其称为受信任的证书的原因在于,密钥存储库所有者信任该证书中的公钥的确属于由该证书的主体(所有者)所标识的身份。此类条目可用于对其他方进行身份验证。
WebSphere Message Broker 仅支持将 Java 密钥存储库(Java keystore,JKS)用于密钥存储库和信任存储库。
设置密钥存储库的最快方法是创建您自己的证书,称为自签名证书。您最终将获得包含公开证书和私钥的密钥存储库。要设置信任存储库,您需要导出公开证书并将其导入新的信任存储库。信任存储库通常仅包含公开证书。
当 WebSphere Message Broker 接收到消息时,除非设置了选项 Trustany,否则将根据信任存储库中的证书来验证消息中的证书。您可以在图 17 中看到此选项,其中将信任设置为 TrustStore。
WebSphere Message Broker 提供的 keytool 实用工具或 iKeyman 实用工具对密钥存储库进行管理。
下面使用 iKeyman V7.0.3.28 来逐步地创建一个自签名的证书以便分发到服务器。
- 从命令行窗口中(例如在 Microsoft® Windows® 命令提示符中)运行 iKeyman。IBM Key Management 窗口将打开。
- 单击 New > Self-Signed Certificate 并按照提示操作。
- 通过从下拉列表中选择 Personal Certificates(请参见图 1)来获取新的自签名证书的公开位,其中同时包含私有和公开部分。
图 1. Personal Certificates 视图
- 选择您新创建的证书。
- 单击 Extract Certificate,如图 1 所示,以打开 Extract Certificate to a File 窗口。
- 选择数据类型,例如 Based64,然后单击 OK。证书的公开部分将创建为 .arm 文件(请参见图 2)。
图 2. 提取公开部分并将其存储在文件中
- 将该 .arm 文件分发到正在运行 WebSphere Message Broker 的服务器。
- 将该 .arm 文件导入服务器的信任存储库:
- 将 mikescert.arm 文件存储在 server/recipient 计算机上。
- 在 server/recipient 计算机上,运行 iKeyman 以启动 IBM Key Management 工具。
- 从下拉列表中选择 Signer Certificates,如图 3 所示。
图 3. 选择 Signer Certificate 视图
- 单击 Add 以从文件导入公钥。
- 从存储 .arm 文件的位置选择 mikescert.arm,如图 4 所示,然后单击 OK。
图 4. 选择要导入的 ARM 文件
- 为导入的证书提供名称,如图 5 所示,然后单击 OK。
图 5. 命名公开证书
- 要检查该信任存储库,可以运行 keytool 实用工具以显示内容。从命令行输入
keytool -list -keystore c:\argo\security\server.keystore –v
。清单 1 显示了此命令的典型输出。
清单 1. keytool 命令的典型输出Alias name: mikespublickey Creation date: 06-Mar-2008 Entry type: trustedCertEntry Owner: CN=KDHMT99.hursley.ibm.com, C=GB Issuer: CN=KDHMT99.hursley.ibm.com, C=GB Serial number: 47cfeaf6 Valid from: 06/03/08 13:00 until: 06/03/09 13:00 Certificate fingerprints: MD5: 36:52:BF:C0:E4:67:6F:E2:3F:1E:00:91:5D:0B:8A:54 SHA1: F4:50:21:6B:16:60:A3:3B:ED:56:59:AE:03:1A:E6:5D:52:DC:57:66
- 现在您已经填充了信任存储库和密钥存储库,下面可以运行
mqsichangeproperties
命令(并将对象名称设置为ComIbmJVMManager
)来为 WebSphere Message Broker 定义密钥存储库。 - 为 WebSphere Message Broker(针对所有执行组)设置密钥存储库属性,或在 WebSphere Message Broker(此示例使用了 2008年 5 月发布的 WebSphere Message Broker V6.1 GA2 版本)中为某个单独的执行组设置密钥存储库属性。清单 2 为名为 test_brk 的 WebSphere Message Broker 和名为 testexecutiongroupname 的执行组设置密钥存储库。从 WebSphere Message Broker 控制台中使用下面的命令。
清单 2. 为执行组定义密钥存储库mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystoreFile -v [Location of server keystore] mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystoreType -v JKS mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n keystorePass -v testexecutiongroupname Keystore::password
有关 mqsichangeproperties 命令的更多信息,请访问 WebSphere Message Broker 信息中心(请参阅参考资料)。
- 下面为 WebSphere Message Broker 的执行组定义信任存储库。对于此定义,请指定
truststoreFile
、truststoreType
和truststorePass
并附带–n
参数,如清单 3 所示。
清单 3. 定义执行组的信任存储库mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n truststoreFile -v [Location of server truststore] mqsichangeproperties test_brk -e testexecutiongroupname -o ComIbmJVMManager -n truststoreType -v JKS mqsichangeproperties 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;请注意,必须停止 WebSphere Message Broker 才能完成此操作。清单 6 显示了该命令的情况。
mqsisetdbparms test_brk -n brokerTruststore::password -u temp -p pa55word |
此时,您已经设置并定义了密钥存储库,并且您已经准备好了解有关签名的更多信息了。
您希望验证发送到接收者的消息还没有被篡改。任何人都可以阅读该消息中的数据,但是您可以检查内容的完整性。
为此,可以应用 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 以允许流签名所需要的步骤。