Set the client for response digital signature verification: choosing the verification method

Set the client for response digital signature verification: choosing the verification method

Configure the WS-Security extensions and WS-Security bindings using the WS extension tab and the WS binding tab in the Web services editor within an assembly tool.
There is an important distinction between Version 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 V6.0.x and later applications. Prior to completing these steps, read either of the following topics to become familiar with the WS extension tab and the WS binding tab in the Web services editor within the IBM assembly tools:

Set the server security bindings using an assembly tool
Set the server security bindings

Use these two tabs to configure the WS-Security extensions and WS-Security bindings, respectively. Also, specify which message parts contain digital signature information that must be verified by the client. See Set the client for response digital signature verification: verifying the message parts to specify which message parts are digitally signed by the server and must be verified by the client. The message parts specified for the server response sender must match the message parts specified for the client response receiver. Likewise, the digital signature method chosen for the server must match the digital signature method used by the client.
Complete the following steps to configure the client for response digital signature verification. The steps describe how to modify the extensions to indicate which digital signature method the client will use during verification.

Launch an assembly tool.
See the related information on Assembly Tools.
Switch to the Java EE perspective. Click Window > Open perspective > Other > J2EE.
Click Application Client Projects > application_name > appClientModule > META-INF.
Right-click the application-client.xml file, select Open with > Deployment descriptor editor.
Click the WS Binding tab.
Expand the Security response receiver binding configuration > Signing information section.
Click Edit to select a digital signature method.
The signing info dialog displays and either select or enter the following information:

Canonicalization method algorithm
Digest method algorithm
Signature method algorithm
Signing key name
Signing key locator

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 the following definitions are based on the XML-Signature specification, which can be found at: http://www.w3.org/TR/xmldsig-core.

Table 1. Digital signature methods

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.
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 used to convert the canonicalized <SignedInfo> element into the <SignatureValue> element. 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. To validate this public key at the receiving end, configure a certificate path reference. By selecting User certificate path reference, 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 keystore that contains trusted, self-signed certificates and certificate authority (CA) certificates. These certificates are trusted certificates that we can use with any applications in the deployment.
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 the deployment, but might be used as an intermediary to validate certificates for an application.

Select Show only FIPS Compliant Algorithms if we only want the FIPS compliant algorithms to be shown in the Signature method algorithm and Digest method algorithm dropdown lists. Use this option if we expect this application to be run on a WAS that has set the Use the United States FIPS (FIPS) algorithms option in the SSL certificate and key management panel of the admin console for WAS.

Results

If we 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. 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. Set the actor in the following locations in the Web services editor within an assembly tool:

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. we have specified which method the client uses to verify the digital signature in the message parts.

Next steps
After you configure the server for response signing and the client for request digital signature verification, verify that you have configured the client and the server to handle the message request.

Related concepts

Trust anchors
Collection certificate store
Assembly tools

Related tasks

Set the server security bindings using an assembly tool
Set the server security bindings
Set the client for response digital signature verification: verifying the message parts
Set trust anchors using an assembly tool
Set trust anchors
Set the server-side collection certificate store using an assembly tool
Set the client-side collection certificate store using an assembly tool
Set the client-side collection certificate store
Set default collection certificate stores at the server level in the WAS admin console
Secure Web services for V5.x applications using XML digital signature

Related information

XML-Signature Syntax and Processing: W3C Recommendation 12 February 2002

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.
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 used to convert the canonicalized <SignedInfo> element into the <SignatureValue> element. 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. To validate this public key at the receiving end, configure a certificate path reference. By selecting User certificate path reference, 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 keystore that contains trusted, self-signed certificates and certificate authority (CA) certificates. These certificates are trusted certificates that we can use with any applications in the deployment.
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 the deployment, but might be used as an intermediary to validate certificates for an application.