Creating a Message Security Provider

To create a new message security provider, follow these steps. To configure an existing provider, follow the steps in "Configuring a Message Security Provider".

  1. In the Admin Console tree component, expand the Configuration node.
  2. Expand the Security node.
  3. Expand the Message Security node.
  4. Select the SOAP node.
  5. Select the Providers tab.
  6. On the Provider Configuration page, click New.
  7. In the Provider Config section of the Create a Provider Configuration page, enter the following:
  8. In the Request Policy section of the Create a Provider Configuration page, enter the following optional values, if needed. These properties are optional, but if not specified, no authentication is applied to request messages.
  9. For more information on the resulting actions of the various security policy configurations performed by the WSS provider authentication modules for those configurations, see "Actions of Request and Response Policy Configurations".

  10. In the Response Policy section of the Create a Provider Configuration page, enter the following optional properties, if needed. These properties are optional, but if not specified, no authentication is applied to response messages.
  11. For more information on the resulting actions of the various security policy configurations performed by the WSS provider authentication modules for those configurations, see "Actions of Request and Response Policy Configurations".

  12. Add additional properties by clicking the Add Property button. The provider that is shipped with the Application Server supports the property listed below. If other providers are used, refer to its documentation for more information on properties and valid values.
  13. Click OK to save this configuration, or click Cancel to quit without saving.

Equivalent asadmin command: create-message-security-provider

See also:

Actions of Request and Response Policy Configurations

Table 0-1 shows possible security policy configurations and the resulting set and order of security operations performed by the WSS provider authentication modules for that configuration.

Table 0-1   Security policy configurations and the corresponding (basic) actions performed by the WSS Provider auth modules

Security Policy Configuration

Set and Order of Security Operations performed by the WSS Provider auth module

auth-source="sender"

[1.1] Client module sends a wsse:UsernameToken in the wsse:Security header of the SOAP request. The client security configuration file MUST have an xwss:Authenticate element with a nested xwss:UsernameAndPassword element containing the properties of the Token. The username and password are obtained by the ClientSecurityAuthModule during runtime via javax.security.auth.NameCallback and javax.security.auth.PasswordCallback; the values specified in the security configuration file are ignored.

[1.2] Server module expects a wsse:UsernameToken in the request and the server security configuration file MUST have an xwss:requireAuthentication element specifying the server requirements specific to the token. The values of all attributes (of xwss:requireAuthentication) MUST be false.

auth-source="content"

[2.1] Client module sends a digital signature along with the SOAP request and the client side security configuration file MUST have an xwss:Sign element, including in it the alias of the client certificate to be used for signing (specified using senderCertificateAlias). The SOAP body of the request is signed. The key reference mechanism used is DirectReference. A single ds:Signature element is found in the wsse:Security header.

[2.2] Server module expects a client signed request and the server security configuration file MUST have an xwss:requireSignature element specifying the target (should be SOAP Body) of the signature via a nested Target element. It should also include attributes signTokenRequired (should be false) unless the key bearing token used by the client to sign the message is also included in the signature. The key reference mechanism must match the value specified in the client security configuration, which defaults to Direct (DirectReference). A single ds:Signature element is expected in the wsse:Security header.

auth-source="sender"

auth-recipient=
"before-content"

[3.1] Client module encrypts the SOAP Body of request (first) and sends a UsernameToken in the wsse:Security header. The effect of these operations is that the wsse:Security header contains an wsse:UsernameToken followed by an xenc:EncryptedKey. The content of the SOAP Body is replaced with xenc:EncryptedData.

The client side security configuration file MUST have an <xwss:Authenticate> element with a nested xwss:UsernameAndPassword element containing the properties of the Token and xwss:Encrypt element containing the alias of the receiver’s certificate, specified using receiverCertificateAlias, with which it encrypts a symmetric key used for encrypting the body. Refer to [1.1]

[3.2] Server module expects a wsse:UsernameToken (authenticates source first) in the wsse:Security header and an encrypted message body (performs decryption later). The server security configuration file MUST have an xwss:requireAuthentication element specifying the server requirements specific to the token and an xwss:requireEncryption element specifying the target of the encryption via a nested Target element (should be SOAP body). The encryptContentRequired attribute should be true, implying the content of the SOAP Body has to be encrypted. The key reference type mechanism expected is Direct (DirectReference).

auth-source="sender"

auth-recipient=
"after-content"

Refer [3.1] & [3.2]

The operations performed are reversed in order: the token is exported first and the body of the message is encrypted later. The server security module performs decryption first and then authenticates the sender of the message.

The SOAP request should contain an xenc:EncryptedKey followed by an wsse:UsernameToken in the wsse:Security header. The content of the SOAP body should be replaced with an xenc:EncryptedData element.

auth-source="content"

auth-recipient=
"before-content"

[5.1] Client module encrypts the SOAP Body of request (first) and signs it (encrypted body) later. The effect of this is that the wsse:Security header contains a ds:Signature element at the top followed by an xenc:EncryptedKey. The content of the SOAP body is replaced with an xenc:EncryptedData element.

[5.2] Server module expects a signed message (performs signature verification first) with an encrypted message body (performs decryption later).

auth-source="content"

auth-recipient=
"after-content"

Refer [5.1] & [5.2]

The operations performed are reversed in order: the body of the message is signed first and is encrypted later. The server security module performs decryption (recipient authentication) first followed by source authentication.

The SOAP request should contain xenc:EncryptedKey followed by an ds:Signature element in the wsse:Security header. The content of the SOAP Body should be replaced with an xenc:EncryptedData element.

auth-recipient=
"before-content"

OR

auth-recipient=
"after-content"

[7] The SOAP request (body of the message) is encrypted. An xenc:EncryptedKey is found in the wsse:Security header. The content of the SOAP Body is replaced with an xenc:EncryptedData element.

No policy specified.

No security operations are performed by the modules.

Rules for Performing Multiple Sign/Encrypt Operations

The authentication providers can perform multiple sign/encrypt operations when a corresponding flag is set on the request and/or response policies. The rules for mapping are as shown in Table 0-2.

Table 0-2   Rules for Mapping

Security Policy

Security Operations that can be performed by the modules

auth-source="content"

Multiple sign operations can be performed.

The operations are performed in the order the xwss:Sign elements appear in the configuration file.

auth-recipient=
"before-content"

OR

auth-recipient=
"after-content"

Multiple encrypt operations can be performed.

The operations are performed in the order the xwss:Encrypt elements appear in the configuration file.

auth-source="sender"

auth-recipient=
"before-content"

OR

auth-recipient=
"after-content"

Multiple encrypt operations can be performed before/after (depending upon auth-recipient flag) along with sending a UsernameToken.

The encrypt operations are performed in the order the xwss:Encrypt elements appear in the config. file.

auth-source="content"

auth-recipient=
"before-content"

OR

auth-recipient=
"after-content"

Multiple encrypt operations can be performed before/after (depending upon aJuth-recipient flag) along with a digital signature.

Same order rules as above.


Legal Notices