Set the client for request signing: digitally signing message parts

To configure the client for request signing, specify which message parts to digitally sign when configuring the client.

There is an important distinction between V 5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V 6.0.x and later applications. Prior to completing these steps, read either of the following topics to become familiar with the Security Extensions tab and the Port Binding tab in the Web Services Client Editor within an assembly tool.

• Set the client security bindings using an assembly tool
• Set the security bindings on a server acting as a client

These two tabs are used to configure the WS-Security extensions and the WS-Security bindings, respectively.

Complete the following steps to specify which message parts to digitally sign when configuring the client for request signing:

 

1. Launch an assembly tool.

   See the related information on Assembly Tools.

2. Click Window > Open perspective > Other > J2EE.

3. Click Application Client projects > application_name > appClientModule > META-INF.

4. Right-click the application-client.xml file, select Open with > Deployment Descriptor Editor, and click the WS Extension tab.

   The Client Deployment Descriptor is displayed.

5. Expand Request sender configuration > Integrity. Integrity refers to digital signature while confidentiality refers to encryption. Integrity decreases the risk of data modification while the data is transmitted across the Internet.

   See on digitally signing SOAP messages, see XML digital signature.

6. Indicate which parts of the message to sign by clicking Add and selecting body, timestamp, or SecurityToken.

   The following list contains descriptions of the message parts

   body

   The body is the user data portion of the message.

   timestamp

   The time stamp determines if the message is valid based on the time that the message is sent and then received. If timestamp is selected, proceed to the next step and select Add created time stamp to add a time stamp to a message.

   SecurityToken

   The security token authenticates the client. If this option is selected, the message is signed.

   We can choose to digitally sign the message using a time stamp if Add created time stamp is selected and configured. We can digitally sign the message using a security token if a login configuration authentication method is selected.

7. Expand the Add created time stamp section and select this option if we want a time stamp added to the message.

   We can specify an expiration time for the time stamp, which helps defend against replay attacks. The lexical representation for duration is the [ISO 8601] extended format PnYnMnDTnHnMnS, where:

   • nY represents the number of years

   • nM represents the number of months

   • nD represents the number of days

   • T is the date and time separator

   • nH represents the number of hours

   • nM represents the number of minutes

   • nS represents the number of seconds. The number of seconds can include decimal digits to arbitrary precision.

   For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, the format is: P1Y2M3DT10H30M. Typically, you configure a message time stamp for about 10 to 30 minutes, for example, 10 minutes is represented as: P0Y0M0DT0H10M0S. The P character precedes time and date values.

 

Results

If we configure the client and server signing information correctly, but receive a Soap body not signed error when executing the client, we might need to configure the actor. We can configure the actor in the following locations on the client in the Web Services Client Editor within an assembly tool:

• Click Security extensions > Client service configuration details and indicate the actor information in the Actor URI field.

• Click Security extensions > Request sender configuration > Details and indicate the actor information in the Actor field.

You must configure the same actor strings for the Web service on the server, which processes the request and sends the response back. Configure the actor in the following locations:

• Click Security extensions > Server service configuration.

• Click Security extensions > Response sender service configuration details > Details and indicate the actor information in the Actor field.

The actor information on both the client and server must refer to the same exact string. When the Actor fields on the client and server match, the request or response is acted upon instead of being forwarded downstream. The Actor fields might be different when we have Web services acting as a gateway to other Web services. However, in all other cases, make sure that the actor information matches on the client and server. When Web services are acting as a gateway and they do not have the same actor configured as the request passing through the gateway, Web services do not process the message from a client. Instead, these Web services send the request downstream. The downstream process that contains the correct actor string processes the request. The same situation occurs for the response. Therefore, it is important that you verify that the appropriate client and server Actor fields are synchronized.

 

Next steps

After we have specified which message parts to digitally sign, specify which method is used to digitally sign the message. See Set the client for request signing: choosing the digital signature method for more information.

XML digital signature
Request sender
Request receiver
Security token
Assembly tools

 

Related tasks

Set the client security bindings using an assembly tool
Set the client for request signing: choosing the digital signature method
Set the security bindings on a server acting as a client