You can configure the Web Services Security extensions
and Web Services Security bindings using the WS extension tab
and the WS binding tab in the web services
editor within an assembly tool.
Before you begin
Important: There is an important distinction between
Version 5.x and Version 6 and later applications. The information
supports Version 5.x applications only that are used with WebSphere® Application Server Version 6.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
WS
extension tab and the
WS binding tab
in the web services editor within the IBM® assembly
tools:
You can use these two tabs to configure the Web Services Security
extensions and Web Services Security bindings, respectively. Also,
you must specify which message parts contain digital signature information
that must be verified by the client. See
Configuring 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.
About this task
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.
Procedure
- Launch an assembly tool.
For more information,
see the related information on Assembly Tools.
- Switch to the Java™ Platform,
Enterprise Edition (Java EE)
perspective. Click .
- Click .
- Right-click the application-client.xml file,
select .
- Click the WS Binding tab.
- Expand the 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:
https://www.w3.org/TR/xmldsig-core.
Table 1. Digital signature methods . Use the methods to configure the client for
response digital signature verification.
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 that is 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, 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 keystore 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. |
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. |
- Optional: Select Show only FIPS
Compliant Algorithms if you 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 WebSphere Application Server
that has set the Use the United States Federal Information
Processing Standard (FIPS) algorithms option in the SSL
certificate and key management panel of the administrative console
for WebSphere Application Server.
Results
Important: If you configure the client and server
signing information correctly, but receive a
Soap body not
signed
error when running the client, you might need to configure
the actor. You can configure the actor in the following locations
on the client in the web services client editor within an assembly
tool:
- Click and indicate the actor information in the Actor URI
field.
- Click 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. Configure the actor in the following locations in the web services
editor within an assembly tool:
- Click .
- Click 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, 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.
You have specified which
method the client uses to verify the digital signature in the message
parts.
What to do next
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.