Configure the server for request digital signature verification: choosing the verification method

Configure the server for request digital signature verification: choosing the verification method

To configure server for request digital signature verification, use an assembly tool to modify the extensions and indicate which digital signature method the server will use during verification.

Important: There is an important distinction between Version 5.x and Version 6 and later applications. The information supports Version 5.x applications only used with WAS v6.0.x and later. The information does not apply to Version 6.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:

Configure the server security bindings using an assembly tool

Configure the server security bindings using the administrative console
We can use these two tabs to configure the Web Services Security extensions and Web Services Security bindings, respectively. Specify which message parts contain digital signature information that must be verified by the server. See Configure the server for request digital signature verification: Verify the message parts. The message parts specified for the client request sender must match the message parts specified for the server request receiver. Likewise, the digital signature method chosen for the client must match the digital signature method used by the server.
Complete the following steps to configure the server for request digital signature verification. The steps describe how to modify the extensions to indicate which digital signature method the server will use during verification.

Launch an assembly tool. For more information, see the related information on Assembly Tools.

Switch to the Java EE perspective. Click Window > Open perspective > Other > J2EE.

Click EJB Projects > application_name > ejbModule > META-INF.

Right-click the webservices.xml file, and click Open with > Web services editor.

Click the Binding Configurations tab.

Expand the Security request receiver binding configuration details > Signing information section.

Click Edit to edit the signing information. The signing information dialog is displayed, select or enter the following information:

Canonicalization method algorithm

Digest method algorithm

Signature method algorithm

Use certificate path reference

Trust anchor reference

Certificate store reference

Trust any certificate
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 is located at the following web address: http://www.w3.org/TR/xmldsig-core.

Name Purpose
Canonicalization method algorithm Canonicalizes 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 Applies to the data after transforms are applied, if specified, to yield the <DigestValue> element. The signing of the <DigestValue> element 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 Converts the canonicalized <SignedInfo> element into the <SignatureValue> element. 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 Validates a certificate or signature sent with a message. 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, 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 Refers to a key store containing 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 Contains 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.

Optional: 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 you expect this application to be run on a WAS that has set the Use the United States FIPS algorithms option in the SSL certificate and key management panel of the administrative console.

Results

Important: 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. We can configure the actor in the following locations on the client:

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.

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 you 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 that the appropriate client and server actor fields are synchronized. You have specified the method that the server uses to verify the digital signature in the message parts.

What to do next
After you configure the client for request signing and the server for request digital signature verification, configure the server and the client to handle the response. Next, specify the response signing for the server. See Configure the server for response signing: digitally signing message parts for more information.

Related concepts

XML digital signature
Request sender
Request receiver
Development and assembly tools

Related tasks

Configure the server security bindings using an assembly tool
Configure the server security bindings using the administrative console
Configure the server for request digital signature verification: Verify the message parts
Configure trust anchors using an assembly tool
Configure trust anchors using the administrative console
Configure the server-side collection certificate store using an assembly tool
Configure the client-side collection certificate store using an assembly tool
Configure the client-side collection certificate store using the administrative console
Configure default collection certificate stores at the server level in the WAS administrative console
Configure the server for response signing: digitally signing message parts

Related information:

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

Name	Purpose
Canonicalization method algorithm	Canonicalizes 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	Applies to the data after transforms are applied, if specified, to yield the <DigestValue> element. The signing of the <DigestValue> element 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	Converts the canonicalized <SignedInfo> element into the <SignatureValue> element. 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	Validates a certificate or signature sent with a message. 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, 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	Refers to a key store containing 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	Contains 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.