创建消息安全性提供者

要创建新的消息安全性提供者,请执行以下步骤。要配置现有提供者,请执行配置消息安全性提供者中的步骤。

  1. 在管理控制台的树组件中,展开“配置”节点。
  2. 选择要配置的实例:
    1. 要配置特定的实例,请选择该实例的配置节点。例如,对于默认实例 server,请选择 server-config 节点。
    2. 要配置所有实例的默认设置,请选择 default-config 节点。
  3. 展开“安全性”节点。
  4. 展开“消息安全性”节点。
  5. 选择 "SOAP" 节点。
  6. 选择“提供者”选项卡。
  7. 在“提供者配置”页面中,单击“新建”。
  8. 在“创建提供者配置”页面的“提供者配置”部分,输入以下信息:
  9. 在“创建提供者配置”页面的“请求策略”部分,根据需要输入以下可选值。这些属性是可选的,但如果不指定这些属性,将不会对请求消息执行任何验证。
  10. 有关 WSS 提供者验证模块执行的各种安全策略配置的结果性操作的更多信息,请参见请求策略配置和响应策略配置的操作

  11. 在“创建提供者配置”页面的“响应策略”部分,根据需要输入以下可选属性。这些属性是可选的,但如果不指定这些属性,将不会对响应消息执行任何验证。
  12. 有关 WSS 提供者验证模块执行的各种安全策略配置的结果性操作的更多信息,请参见请求策略配置和响应策略配置的操作

  13. 通过单击“添加属性”按钮添加其他属性。Application Server 附带的提供者支持下面列出的属性。如果使用了其他提供者,则有关属性和有效值的更多信息,请参阅其他提供者的文档。
  14. 单击“确定”保存此配置,或单击“取消”退出而不保存更改。

等效的 asadmin 命令为:create-message-security-provider

另请参见:

请求策略配置和响应策略配置的操作

表 0-1 显示了可能的安全策略配置,以及由 WSS 提供者验证模块针对这些配置而执行的安全操作的结果集和顺序。

表 0-1  安全策略配置以及由 WSS 提供者验证模块所执行的相应(基本)操作

安全策略配置

由 WSS 提供者验证模块执行的安全操作的集和顺序

auth-source="sender"

[1.1] 客户机模块在 SOAP 请求的 wsse:Security 标头中发送 wsse:UsernameToken。客户机安全性配置文件必须具有 xwss:Authenticate 元素(该元素具有包含令牌属性的 xwss:UsernameAndPassword 嵌套元素)。ClientSecurityAuthModule 在运行时过程中通过 javax.security.auth.NameCallbackjavax.security.auth.PasswordCallback 获取用户名和密码;在安全性配置文件中指定的值将被忽略。

[1.2] 服务器模块要求在请求中有 wsse:UsernameToken。服务器安全性配置文件必须具有 xwss:requireAuthentication 元素来指定特定于令牌的服务器要求。(xwss:requireAuthentication 元素的)所有属性值都必须为 false

auth-source="content"

[2.1] 客户机模块随 SOAP 请求发送数字签名。客户端安全性配置文件必须具有 xwss:Sign 元素,其中包括要用于签名的客户机证书的别名(使用 senderCertificateAlias 指定)。对请求的 SOAP 主体进行签名。所用的密钥引用机制为 DirectReference。在 wsse:Security 标头中找到单个 ds:Signature 元素。

[2.2] 服务器模块要求有一个客户机签名的请求。服务器安全性配置文件必须具有 xwss:requireSignature 元素,以通过嵌套的 Target 元素指定签名的目标(应为 SOAP 主体)。该文件还应当包括属性 signTokenRequired(应为 false),除非客户机用来对消息进行签名的包含令牌的密钥也包括在该签名中。密钥引用机制必须与客户机安全性配置中指定的值匹配,默认为 Direct (DirectReference)。wsse:Security 标头中要求有单个 ds:Signature 元素。

auth-source="sender"

auth-recipient=
"before-content"

[3.1] 客户机模块(先)对请求的 SOAP 主体进行加密,然后在 wsse:Security 标头中发送 UsernameToken。这些操作的结果是:wsse:Security 标头包含后面跟有 xenc:EncryptedKeywsse:UsernameToken。用 xenc:EncryptedData 替换 SOAP 主体的内容。

客户端安全性配置文件必须具有 <xwss:Authenticate> 元素(该元素具有包含令牌属性的 xwss:UsernameAndPassword 嵌套元素),还必须具有包含收件人证书别名(使用 receiverCertificateAlias 指定)的 xwss:Encrypt 元素,使用该元素可以对用于主体加密的对称密钥进行加密。请参阅 [1.1]。

[3.2] 服务器模块要求在 wsse:Security 标头中有 wsse:UsernameToken(先验证源),并要求有加密的消息主体(然后进行加密)。服务器安全性配置文件必须具有 xwss:requireAuthentication 元素(该元素指定特定于令牌的服务器要求),还必须具有 xwss:requireEncryption 元素(该元素通过嵌套的 Target 元素 [应为 SOAP 主体] 指定加密目标)。encryptContentRequired 属性应为 true,表示必须对 SOAP 主体的内容进行加密。要求的密钥引用类型机制为 Direct (DirectReference)。

auth-source="sender"

auth-recipient=
"after-content"

请参阅 [3.1] 和 [3.2]

以相反的顺序执行上面的操作:先导出令牌,然后对消息主体进行加密。服务器安全性模块先执行解密,然后验证消息发件人。

SOAP 请求应在 wsse:Security 标头中包含后面跟有 wsse:UsernameTokenxenc:EncryptedKey。应当用 xenc:EncryptedData 元素替换 SOAP 主体的内容。

auth-source="content"

auth-recipient=
"before-content"

[5.1] 客户机模块(先)对请求的 SOAP 主体进行加密,然后对其(加密的主体)进行签名。这样做的结果是:wsse:Security 标头的顶部包含 ds:Signature 元素,该元素后面跟有 xenc:EncryptedKey。SOAP 主体的内容被替换为 xenc:EncryptedData 元素。

[5.2] 服务器模块要求有一则签名的消息(先执行签名验证),该消息具有加密的消息主体(然后执行加密)。

auth-source="content"

auth-recipient=
"after-content"

请参阅 [5.1] 和 [5.2]

以相反的顺序执行上面的操作:先对消息主体进行签名,然后进行加密。服务器安全性模块首先执行解密(收件人验证),然后执行源验证。

SOAP 请求应在 wsse:Security 标头中包含后面跟有 ds:Signature 元素的 xenc:EncryptedKey。应当用 xenc:EncryptedData 元素替换 SOAP 主体的内容。

auth-recipient=
"before-content"

auth-recipient=
"after-content"

[7] 对 SOAP 请求(消息主体)进行加密。在 wsse:Security 标头中找到 xenc:EncryptedKey。SOAP 主体的内容被替换为 xenc:EncryptedData 元素。

未指定策略。

模块未执行任何安全操作。

执行多次签名/加密操作的规则

如果针对请求和/或响应策略设置了响应标志,则验证提供者可以执行多次签名/加密操作。映射的规则如表 0-2 所示。

表 0-2  映射规则

安全策略

模块可以执行的安全操作

auth-source="content"

可以执行多次签名操作。

按照配置文件中 xwss:Sign 元素的显示顺序来执行这些操作。

auth-recipient=
"before-content"

auth-recipient=
"after-content"

可以执行多次加密操作。

按照配置文件中 xwss:Encrypt 元素的显示顺序来执行这些操作。

auth-source="sender"

auth-recipient=
"before-content"

auth-recipient=
"after-content"

可以在发送 UsernameToken 之前/之后(取决于 auth-recipient 标志)执行多次加密操作。

按照配置文件中 xwss:Encrypt 元素的显示顺序执行加密操作。

auth-source="content"

auth-recipient=
"before-content"

auth-recipient=
"after-content"

可以在进行数字签名之前/之后(取决于 aJuth-recipient 标志)执行多次加密操作。

与上面的顺序规则相同。


法律通告