Configure the Web services client for response digital signature verification

This task provides the steps needed to configure the client for response digital signature verification. Use these steps to modify the extensions that indicate which parts of the message must be verified. Also, use these steps to configure the bindings that indicate how these parts of the message must be verified.

Perform the following steps in the WebSphere Development Studio Client for iSeries to configure the parts of the SOAP message in which the digital signature must be verified:

1. Open the webservicesclient.xml file in the Web Services Client Editor of the WebSphere Development Studio Client for iSeries. For more information, see Configure your Web services application.

2. Click the Security Extensions tab.

3. Expand the Response Receiver Configuration --> Required Integrity settings. Required Integrity refers to message parts that require digital signature verification. Digital signature verification decreases the risk that the message parts have been modified while the message is transmitted across the Internet. For more conceptual information on digital signature, see XML digital signature.

4. Select the parts of the message that must be verified. You can determine which parts of the message to select by looking at the Web service response sender configuration. To add parts of the message, click Add and select one of the following three parts:

   • Body
     This is the user data portion of the message.

   • Timestamp
     The time stamp determines if the message is valid based on the time the message was sent and then received. If timestamp is selected, you can expand Response Receiver Configuration --> Add Received Time Stamp to add the received time stamp to the message.

   • Securitytoken
     The security token authenticates the client. If Securitytoken is selected, the message is signed.

5. (Optional) If you have configured the client and server signing information correctly, but you receive a "Soap body not signed" error when you run the client, you may need to configure the actor in the following locations on the client in the Web Services Client Editor:

   • Click Security Extensions --> Client Service Configuration Details and indicate the actor information in the ActorURI field.
   • Click Security Extensions --> Request Sender Configuration section --> Details and indicate the actor information in the Actor field.

   Also, configure the same actor strings for the Web service on the server, which processes the request and sends the response back. You can do this from the following location in the Web Services Editor:

   • Click Security Extensions --> Server Service Configuration section. Make sure that the Actor URI field contains the same actor string that is indicated on the client side.
   • 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, then the request or response is acted upon instead of being forwarded downstream. The actor fields might be different when you 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.

6. Save the file.

Next, perform the following steps in the Web Services Client Editor to configure the information that is needed to verify digital signatures:

1. Click the Port Binding tab.

2. Expand the Security Response Receiver Binding Configuration --> Signing Information settings. Click Edit to view the signing information. The following table describes the purpose for each of these selections. Some of these definitions are based on the XML-Signature Syntax and Processing specification (http://www.w3.org/TR/xmldsig-core).

   Name	Purpose
   Canonicalization method algorithm	The canonicalization method is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation.
   Digest method algorithm	The digest method algorithm is the algorithm applied to the data after transforms are applied, if specified, to yield the <DigestValue>. The signing of the DigestValue binds resource content to the signer key. The algorithm selected for the client response receiver configuration must match the algorithm selected in the server response sender configuration.
   Signature method algorithm	The signature method is the algorithm that is used to convert the canonicalized <SignedInfo> into the <SignatureValue>. The algorithm selected for the client response receiver configuration must match the algorithm selected in the server response sender configuration.
   Use certificate path reference or Trust any certificate	When a message is signed, the public key used to sign it is transmitted with the message. In order to validate this public key at the receiving end, you should configure a certificate path reference. By selecting User certificate path reference, you must configure a trust anchor reference and certificate store reference to validate the certificate sent with the message. By selecting trust any certificate, the signature is validated by the certificate sent with the message without the certificate itself being validated.
   Use certificate path reference --> Trust anchor reference	A trust anchor is a configuration that refers to a key store containing trusted self-signed and certificate authority (CA) certificates. These are trusted certificates for any application in your deployment. Refer to Configure trust anchors for more information.
   Use certificate path reference --> Certificate store reference	A certificate store is a configuration that contains a collection of X.509 certificates that are not trusted for all applications in your deployment, but might be used to validate certificates for an application as an intermediary.

3. Save the file.