Migrate the server-side extensions configuration

 

Overview

This article provides general information about migrating the Web services security server-side extensions configuration for a Java 2 Platform, Enterprise Edition (J2EE) V1.3 application to a J2EE V1.4 application. The steps are based on typical scenarios, but the steps are not all-inclusive.

The following table lists the mappings for the top-level sections under the server-side Security Extensions tab within an assembly tool from a J2EE V1.3 application to a J2EE V1.4 application.

Table 1. The mapping of the configuration sections
J2EE V1.3 extensions configuration J2EE V1.4 extensions configuration
Request Receiver Service Configuration Details Request Consumer Service Configuration Details
Response Sender Service Configuration Details Response Generator Service Configuration Details

For information about the assembly tools that are available for WAS v6.x, see Assembly tools.

Consider the following steps to migrate the server-side extensions from a J2EE V1.3 application to a J2EE V1.4 application. These steps are dependent upon your specific configuration.

 

Steps for this task (dependent on configuration)

  • Import the J2EE V1.3 application into an assembly tool and identify all the message parts that are required to be signed and encrypted. The message parts are listed in the Required Integrity and Required Confidentiality sections under the Request Receiver Service Configuration Details section. In a J2EE V1.4 application, these message parts map to the Message parts field of the Required integrity and Required confidentiality dialogs windows within the assembly tool. To specify these message parts within an assembly tool, complete the following steps in the Web Services editor:

    1. Click the Extensions tab.

    2. Navigate to the Required integrity subsection within the Request Consumer Service Configuration Details section.

    3. Specify each message part to be signed in the Message Parts field.

    For example, if the message part in the J2EE V1.3 application is body, we need to specify body in the Message parts keyword field. Similarly, on the Extensions tab, configure the message parts to be encrypted using the Required Confidentiality dialog. Also, for all the message parts that are migrated from a J2EE V1.3 application, select http://www.ibm.com/websphere/webservices/wssecurity/dialect-was in the Message parts dialect field and Required in the Usage type field.

  • Optional: Configure the Required Security Token and Caller Part sections on the Extensions tab if the authentication method of BasicAuth is configured under the Login Config section of the J2EE Version 1.3 application. When you configure the Required Security Token section, select Username in the name field and Required in the Usage type field within the Required Security Token Dialog window. The following table shows how the authentication method values for a J2EE V1.3 application map to the token type values within the J2EE V1.4 application.

    Table 2. Authentication method to token type mappings
    Login Config Authentication method values in the J2EE V1.3 extensions configuration Token type values in the J2EE V1.4 extensions configuration
    BasicAuth UsernameToken
    Signature X509 certificate
    LTPA LTPAToken
    If the authentication method value is IDAssertion within the Login Config section, the token type that specify in the J2EE V1.4 application depends upon the IDType value within the IDAssertion section. The following table shows how the IDType values for J2EE V1.3 application map to the token type values in the J2EE V1.4 application.

    Table 3. IDType values to token type mappings
    IDType values in the J2EE V1.3 application extensions configuration Token type values in the J2EE V1.4 application extensions configuration
    X509Certificate X509 certificate
    Username Username

  • Select the appropriate token type in the Name field of the Call Part Dialog window based on the previous two tables. Select the Username token type when you are configuring the caller part for the basic authentication method. Configuring the other token types in the Caller part dialog is similar to configuring token types in the Required Security Token dialog. If we need to map the IDAssertion authentication method from a J2EE V1.3 application to a J2EE V1.4 application, select the Use IDAssertion option and configure the ID assertion section of the Caller Part Dialog window. The Trust Mode field under the IDAssertion section maps to the Trust method name field of the Trust method property section in the Caller Part Dialog window. If Signature is selected for the Trust method, specify the Required Integrity part that specifies the signature of the trusted intermediary certificate.

  • Configure a nonce in the v6.x Binding Configurations section if nonce is specified in the Add Authentication Method dialog under Login Config within the J2EE V1.3 application extensions configuration. Important: Nonce is configured in the bindings for a J2EE V1.4 application and not in the extensions.

    To configure a nonce on the Binding Configurations tab, set the com.ibm.wsspi.wssecurity.token.Username.verifyNonce property in the Token Consumer configuration for the Username token.

  • Configure the Add Timestamp section to migrate the time stamp information if the <addReceivedTimestamp> element is configured in the J2EE V1.3 extensions. To migrate the Response Sender Service Configuration Details section in the J2EE V1.3 extensions, identify all of the message parts listed within the Integrity and Confidentiality sections. Configure these message parts using the Integrity and Confidentiality dialogs under the Response Generator Service Configuration details section. This configuration is similar to the configuration for Required Integrity and Required Confidentiality, with the exception of the Order field in the Integrity Dialog. The value of this Order field specifies the order in which the message parts specified in the Message Parts field are digitally signed or encrypted in the Simple Object Access Protocol (SOAP) message. For example, the extensions contain the following information:

    • One integrity entry called int_part1 with a value of 1 in the Order field

    • One confidentiality entry called conf_part1 with a value of 2 in the Order field

    In this example, the message parts that are specified by the int_part1 integrity entry are signed before the message parts specified by the conf_part1 confidentiality entry are encrypted. The same rule for the order attribute applies for multiple integrity or confidentiality elements.

 

Result

This set of steps describe the types of information that we need to migrate the Web services security server-side extensions for a J2EE Version 1.3 application to a J2EE V1.4 application.

 

What to do next

Migrate the client-side extensions for a J2EE V1.3 application to a J2EE V1.4 application. For more information, see Migrating the client-side extensions configuration.


 

See Also


Assembly tools

 

Related Tasks


Migrating the client-side extensions configuration
Migrating the server-side bindings file
Migrating the client-side bindings file