You can migrate the Web Services Security server-side extensions
configuration for a Java™ Platform,
Enterprise Edition (Java EE)
Version 1.3 application to a Java EE
Version 1.4 application for the JAX-RPC programming model.
About this task
The following table lists the mappings for the top-level
sections under the server-side
Security Extensions tab
within an assembly tool from a Java EE
Version 1.3 application to a Java EE
Version 1.4 application.
Table 1. The mapping
of the configuration sections. Use the extensions configuration
information for migration.Java EE
Version 1.3 extensions configuration |
Java EE
Version 1.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 WebSphere® Application Server Version 6.0.x,
see the assembly tools information.
Consider the following steps
to migrate the server-side extensions from a Java EE
Version 1.3 application to a Java EE
Version 1.4 application. These steps are dependent upon your specific
configuration.
Procedure
- Import the Java EE
Version 1.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 Java EE Version 1.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. The steps are based on typical scenarios, but the steps are
not all-inclusive.
- Click the Extensions tab.
- Navigate to the Required integrity subsection within
the Request Consumer Service Configuration Details section.
- Specify each message part to be signed in the Message
Parts field.
For example, if the message part in the Java EE
Version 1.3 application is body, you 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 Java EE Version 1.3 application, you must 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 Java EE
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 Java EE
Version 1.3 application map to the token type values within the Java EE Version 1.4 application.
Table 2. Authentication method
to token type mappings. Use the extensions configuration
information for migration.Login Config Authentication method values in
the Java EE Version 1.3 extensions configuration |
Token type values in the Java EE
Version 1.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 you must specify in the Java EE Version 1.4 application depends upon
the IDType value within the IDAssertion section. The following table
shows how the IDType values for Java EE
Version 1.3 application map to the token type values in the Java EE Version 1.4 application.Table 3. IDType values to token type mappings. Use
the extensions configuration information for migration.IDType values in the Java EE
Version 1.3 application extensions configuration |
Token type values in the Java EE
Version 1.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 you need to map the IDAssertion authentication method from a Java EE Version 1.3 application to a Java EE Version 1.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 버전 9.0 Binding Configurations
section if nonce is specified in the Add Authentication Method dialog
under Login Config within the Java EE
Version 1.3 application extensions configuration.
Important: Nonce is configured in the bindings for a Java EE Version 1.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 Java EE Version 1.3 extensions. To
migrate the Response Sender Service Configuration Details section
in the Java EE Version 1.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 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.
Results
These steps describe the types of information that you need
to migrate the Web Services Security server-side extensions for a Java EE Version 1.3 application to a Java EE Version 1.4 application.
What to do next
Migrate the client-side extensions for a Java EE
Version 1.3 application to a Java EE
Version 1.4 application. For more information, see
Migrating the client-side extensions configuration.