ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzamy_5.4.0.1/50/webserv/wsseccfsignclres.htm

110 lines
8.3 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<!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 client for response digital signature verification</title>
</head>
<BODY>
<!-- Java sync-link -->
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
<h5><a name="wsseccfsignclres"></a>Configure the Web services client for response digital signature verification</h5>
<p>This task provides the steps needed to configure the client for response digital signature verification. Use these steps to modify the extensions that indicate which parts of the message must be verified. Also, use these steps to configure the bindings that indicate how these parts of the message must be verified.</p>
<p>Perform the following steps in the WebSphere Development Studio Client for iSeries to configure the parts of the SOAP message in which the digital signature must be verified:</p>
<ol>
<li><p>Open the webservicesclient.xml file in the Web Services Client 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>Response Receiver Configuration --&gt; Required Integrity</strong> settings. <em>Required Integrity</em> refers to message parts that require digital signature verification. Digital signature verification decreases the risk that the message parts have been modified while the message is transmitted across the Internet. For more conceptual information on digital signature, see <a href="wsseccfxmlsign.htm">XML digital signature</a>.</p></li>
<li><p>Select the parts of the message that must be verified. You can determine which parts of the message to select by looking at the Web service response sender configuration. To add parts of the message, click <strong>Add</strong> and select one of the following three parts:</p>
<ul>
<li><p><strong>Body</strong>
<br>This is the user data portion of the message.</p></li>
<li><p><strong>Timestamp</strong>
<br>The time stamp determines if the message is valid based on the time the message was sent and then received. If <strong>timestamp</strong> is selected, you can expand <strong>Response Receiver Configuration --&gt; Add Received Time Stamp</strong> to add the received time stamp to the message.</p></li>
<li><p><strong>Securitytoken</strong>
<br>The security token authenticates the client. If <strong>Securitytoken</strong> is selected, the message is signed.</p></li>
</ul></li>
<li><p>(Optional) If you have configured the client and server signing information correctly, but you receive a &quot;Soap body not signed&quot; 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 --&gt; Client Service Configuration Details</strong> and indicate the actor information in the <strong>ActorURI</strong> field.</li>
<li>Click <strong>Security Extensions --&gt; Request Sender Configuration section --&gt; 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 --&gt; Server Service Configuration</strong> section. Make sure that the <strong>Actor URI</strong> field contains the same actor string that is indicated on the client side.</li>
<li>Click <strong>Security Extensions --&gt; Response Sender Service Configuration Details --&gt; 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 Client Editor to configure the information that is needed to verify digital signatures:</p>
<ol>
<li><p>Click the <strong>Port Binding</strong> tab.</p></li>
<li><p>Expand the <strong>Security Response Receiver Binding Configuration --&gt; Signing Information</strong> settings. Click <strong>Edit</strong> to view the signing information. 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 is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation.</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 &lt;DigestValue&gt;. 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.</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 &lt;SignedInfo&gt; into the &lt;SignatureValue&gt;. The algorithm selected for the client response receiver configuration must match the algorithm selected in the server response 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 transmitted with the message. In order to validate this public key at the receiving end, you should configure a certificate path reference. By selecting <strong>User certificate path reference</strong>, you must configure a trust anchor reference and 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 --&gt; Trust anchor reference</strong></td>
<td>A trust anchor is a configuration that refers to a key store containing trusted self-signed and certificate authority (CA) certificates. These are trusted certificates for any application in your deployment. Refer to <a href="wsseccftrustanc.htm">Configure trust anchors</a> for more information.</td>
</tr>
<tr valign="top">
<td><strong>Use certificate path reference --&gt; Certificate store reference</strong></td>
<td>A certificate store is a configuration that contains a collection of X.509 certificates that are not trusted for all applications in your deployment, but might be used to validate certificates for an application as an intermediary.</td>
</tr>
</table><p></p></li>
<li><p>Save the file.</p></li>
</ol>
</body>
</html>