WAS v8.5 > Develop applications > Develop web services - Security (WS-Security) > Configure Web Services Security during application assembly > Configure XML digital signature for v5.x web services with an assembly tool

Configure the server for response signing: digitally signing message parts

Use an assembly tool to specify which message parts to digitally sign when configuring the server for response signing.

There is an important distinction between v5.x and v6 and later applications. The information in this topic supports v5.x applications only used with WebSphere Application Server v6.0.x and later. The information does not apply to v6.0.x and later applications.

Prior to completing these steps, read either of the following topics to become familiar with the Extensions tab and the Binding configurations tab in the web services editor within the IBM assembly tools:

These two tabs are used to configure the Web Services Security extensions and the Web Services Security bindings, respectively.

To specify which message parts to digitally sign when configuring the server for response signing:

  1. Launch an assembly tool. For more information, see the related information on assembly tools.
  2. Switch to the Java EE perspective. Click Window > Open perspective > Other > J2EE.

  3. Click EJB Projects > application _name > ejbModule > META-INF.
  4. Right-click the webservices.xml file and click Open with > Web services editor.

  5. Click the Extensions tab, located at the bottom of the Web Services Editor within the assembly tool.

  6. Expand Response sender service configuration details > 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. For more information on digitally signing SOAP messages, see XML digital signature.
  7. Indicate the 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 the message is sent and then received. If this option if selected, proceed to the next step and click Add Created Time Stamp, which indicates the time stamp is added to the message.

    SecurityToken

    The security token is used for authentication. If this option is selected, the authentication information is added to the message.

  8. Optional: Expand the Add created time stamp section. Select this option if you 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. 10 minutes is represented as: P0Y0M0DT0H10M0S. The P character precedes time and date values.


Results

If you configure the client and server signing information correctly, but receive a Soap body not signed error when running the client, we might need to configure the actor. We can configure the actor in the following locations:

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:

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, verify 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 containing the correct actor string processes the request. The same situation occurs for the response. Therefore, it is important that you verify the appropriate client and server actor fields are synchronized. You have specified which message parts to digitally sign when the server sends a response to the client.

After we specifying which message parts to digitally sign, specify which method is used to digitally sign the message. See Configure the server for response signing: choosing the digital signature method for more information.


Related concepts:

XML digital signature
Response sender
Response receiver
Development and assembly tools


Related


Secure web services for v5.x applications using XML digital signature
Configure the client security bindings using an assembly tool
Configure the server security bindings using an assembly tool
Configure the server security bindings
Configure the server for response signing: choosing the digital signature method
Configure the client for response digital signature verification: verifying the message parts
Configure the client for response digital signature verification: choosing the verification method


+

Search Tips   |   Advanced Search