Configure the Web services server for request digital signature verification

Use this task to configure the server for request digital signature verification. The steps describe how to modify the extensions to indicate which parts of the request to verify. Also, the steps describe how to configure the bindings to indicate how to verify the parts of the request.

Perform the following steps in the WebSphere Development Studio Client for iSeries to configure the parts of the Simple Object Access Protocol (SOAP) request that the digital signature must verify:

1. Open the webservices.xml deployment descriptor for your Web services application in the Web Services 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 Request Receiver Service Configuration Details --> Required Integrity settings. Required integrity refers to the parts of the message that require digital signature verification. The purpose of digital signature verification is to make sure that the message parts have not been modified while it was transmitted across the Internet.

4. Select the parts of the message to verify. You can determine which parts of the message to verify by looking at the Web Service Request Sender Configuration in the client application. To add message parts to verify, click Add and select one of the following message parts:

   • Body
     This is the user data in the message.

   • Timestamp
     If selected, a timestamp is added to the message.

   • SecurityToken
     If selected, the authentication information is added to the message.

5. Expand the Add Received Time Stamp section. The Add Received Time Stamp field indicates to validate the Add Created Time Stamp that is configured by the client. You must select option this if you selected Add Created Time Stamp on the client. The time stamp ensures message integrity by indicating the freshness of the request. This option helps to defend against replay attacks.

6. (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 the Actor URI field contains the same actor string that is indicated on the client side.
   • Click Security Extentions --> 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.

7. Save the file.

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

1. Click the Binding Configurations tab.

2. Expand the Security Request Receiver Binding Configuration Details --> Signing Information settings.

3. Click Edit to view the signing information. For more conceptual information on digitally signing SOAP messages, see XML digital signature. 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 algorithm is used to canonicalize the <SignedInfo> element before it is digested as part of the signature operation. The algorithm selected for the server request receiver configuration must match the algorithm selected in the client request sender configuration.
   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 server request receiver configuration must match the algorithm selected in the client request 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 server request receiver configuration must match the algorithm selected in the client request sender configuration.
   Use certificate path reference or Trust any certificate	When a message is signed, the public key used to sign it is sent with the message. This public key or certificate might not be validated at the receiving end. By selecting User certificate path reference, you must configure a trust anchor reference and a 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 that contains trusted, self-signed certificates and certificate authority (CA) certificates. These certificates are trusted certificates that you can use with any applications in your deployment. See Configure trust anchors for more information.
   Use certificate path reference: Certificate store reference	A certificate store is a configuration that has a collection of X.509 certificates. These certificates are not trusted for all applications in your deployment, but might be used as an intermediary to validate certificates for an application.

4. Save the file.