You can migrate the Web services security server-side extensions
configuration for a Java 2 Platform, Enterprise Edition (J2EE) Version
1.3 application to a J2EE Version 1.4 application.
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 J2EE Version 1.3 application to a J2EE Version
1.4 application.
Table 1. The mapping of the configuration sections
J2EE Version 1.3 extensions configuration |
J2EE 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 Assembly tools.
Consider
the following steps to migrate the server-side extensions from a J2EE
Version 1.3 application to a J2EE Version 1.4 application. These steps
are dependent upon your specific configuration.
Procedure
- Import the J2EE 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 J2EE 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 J2EE 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 J2EE
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 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 Version 1.3 application map to the token type values within
the J2EE Version 1.4 application.
Table 2. Authentication method to token type mappings
Login Config Authentication method values in
the J2EE Version 1.3 extensions configuration |
Token type values in the J2EE 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
J2EE Version 1.4 application depends upon the IDType value within
the IDAssertion section. The following table shows how the IDType
values for J2EE Version 1.3 application map to the token type values
in the J2EE Version 1.4 application.
Table 3. IDType values to
token type mappings
IDType values in the J2EE Version 1.3 application
extensions configuration |
Token type values in the J2EE 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 J2EE Version 1.3
application to a J2EE 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 Version
6.0.x Binding Configurations section if nonce is specified in the
Add Authentication Method dialog under Login Config within the J2EE
Version 1.3 application extensions configuration.
Important: Nonce is configured in the bindings for a J2EE 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 J2EE Version 1.3 extensions. To migrate the Response
Sender Service Configuration Details section in the J2EE 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 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.
Results
These steps describe the types of information that you need
to migrate the Web services security server-side extensions for a
J2EE Version 1.3 application to a J2EE Version 1.4 application.