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.