116 lines
8.8 KiB
HTML
116 lines
8.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
|
|
|
<title>Configure the Web services server for request digital signature verification</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h5><a name="wsseccfsignsvreq"></a>Configure the Web services server for request digital signature verification</h5>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ol>
|
|
<li><p>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 <a href="astk.htm">Configure your Web services application</a>.</p></li>
|
|
|
|
<li><p>Click the <strong>Security Extensions</strong> tab.</p></li>
|
|
|
|
<li><p>Expand the <strong>Request Receiver Service Configuration Details --> Required Integrity</strong> settings. <em>Required integrity</em> 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.</p></li>
|
|
|
|
<li><p>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 <strong>Add</strong> and select one of the following message parts:</p>
|
|
<ul>
|
|
<li><p><strong>Body</strong>
|
|
<br>This is the user data in the message.</p></li>
|
|
|
|
<li><p><strong>Timestamp</strong>
|
|
<br>If selected, a timestamp is added to the message.</p></li>
|
|
|
|
<li><p><strong>SecurityToken</strong>
|
|
<br>If selected, the authentication information is added to the message.</p></li>
|
|
</ul></li>
|
|
|
|
<li><p>Expand the <strong>Add Received Time Stamp</strong> section. The <strong>Add Received Time Stamp</strong> field indicates to validate the <strong>Add Created Time Stamp</strong> that is configured by the client. You must select option this if you selected <strong>Add Created Time Stamp</strong> on the client. The time stamp ensures message integrity by indicating the freshness of the request. This option
|
|
helps to defend against replay attacks.</p></li>
|
|
|
|
<li><p>(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:</p>
|
|
<ul>
|
|
<li>Click <strong>Security Extensions --> Client Service Configuration Details</strong> and indicate the actor information in the <strong>ActorURI</strong> field.</li>
|
|
|
|
<li>Click <strong>Security Extensions --> Request Sender Configuration section --> Details</strong> and indicate the actor information in the <strong>Actor</strong> field.</li>
|
|
</ul>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>Click <strong>Security Extensions --> Server Service Configuration</strong> section. Make sure the <strong>Actor URI</strong> field contains the same actor string that is indicated on the client side.</li>
|
|
|
|
<li>Click <strong>Security Extentions --> Response Sender Service Configuration Details --> Details</strong> and indicate the actor information in the <strong>Actor</strong> field.</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p></li>
|
|
|
|
<li><p>Save the file.</p></li>
|
|
</ol>
|
|
|
|
<p>Next, perform the following steps in the Web Services Editor to configure the information that is needed to verify digital signatures:</p>
|
|
|
|
<ol>
|
|
<li><p>Click the <strong>Binding Configurations</strong> tab.</p></li>
|
|
|
|
<li><p>Expand the <strong>Security Request Receiver Binding Configuration Details --> Signing Information</strong> settings.</p></li>
|
|
|
|
<li><p>Click <strong>Edit</strong> to view the signing information. For more conceptual information on digitally signing SOAP messages, see <a href="wsseccfxmlsign.htm">XML digital signature</a>. The following table describes the purpose for each of these selections. Some of these definitions are based on the <a href="http://www.w3.org/TR/xmldsig-core" target="_">XML-Signature Syntax and Processing specification</a> <img src="www.gif" width="18" height="15" alt="Link outside Information Center"> (http://www.w3.org/TR/xmldsig-core).</p>
|
|
|
|
<table border="1" cellpadding="3" cellspacing="0">
|
|
<tr valign="top">
|
|
<th>Name</th>
|
|
<th>Purpose</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Canonicalization method algorithm</strong></td>
|
|
<td>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.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Digest method algorithm</strong></td>
|
|
<td>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.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Signature method algorithm</strong></td>
|
|
<td>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.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Use certificate path reference</strong> or <strong>Trust any certificate</strong></td>
|
|
<td>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 <strong>User certificate path reference</strong>, you must configure a trust anchor reference and a certificate store reference to validate the certificate sent with the message. By selecting <strong>Trust any certificate</strong>, the signature is validated by the certificate sent with the message without the certificate itself being validated.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Use certificate path reference: </strong><strong>Trust anchor reference</strong></td>
|
|
<td>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 <a href="wsseccftrustanc.htm">Configure trust anchors</a> for more information.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Use certificate path reference: Certificate store reference</strong></td>
|
|
<td>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.</td>
|
|
</tr>
|
|
</table><p></p></li>
|
|
|
|
<li><p>Save the file.</p></li>
|
|
</ol>
|
|
|
|
</body>
|
|
</html>
|
|
|