124 lines
8.6 KiB
HTML
124 lines
8.6 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 client for request signing</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h5><a name="wsseccfsignclreq"></a>Configure the Web services client for request signing</h5>
|
|
|
|
<p>This task provides the steps needed to configure the client for request signing. Use these steps to modify the extensions to indicate which parts of the request that you want to sign. Also, use the steps to configure the bindings to indicate how the parts of the request are to be signed.</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 you want to digitally sign:</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 <strong>Request Sender Configuration --> Integrity</strong>. <em>Integrity</em> refers to digital signature while confidentiality refers to encryption. Integrity decreases the risk of data modification while the data is transmitted across the Internet. For more information on digitally signing SOAP messages, see <a href="wsseccfxmlsign.htm">XML digital signature</a>.</p></li>
|
|
|
|
<li><p>Select the parts of the message in which to sign by clicking <strong>Add</strong> and selecting one of the following message 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 time stamp is selected, proceed to the next step to add a created 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>
|
|
|
|
<p>You can choose to digitally sign the message using a time stamp if the <strong>Add Created Time Stamp</strong> field is selected and configured. You can choose to digitally sign the message using a security token if a login configuration authentication method is selected.</p></li>
|
|
|
|
<li><p>Expand the <strong>Add Created Time Stamp</strong> section. Select this if you want a timestamp added to the message. You can additionally specify an expiration time for the timestamp. This helps defend against replay attacks.</p>
|
|
|
|
<p>The lexical representation for duration is the ISO 8601 extended format <tt>P<em>n</em>Y<em>n</em>M<em>n</em>DT<em>n</em>H<em>n</em>M<em>n</em>S</tt>, where the following values apply:</p>
|
|
<ul>
|
|
<li><tt><em>n</em>Y</tt> represents the number of years.</li>
|
|
<li><tt><em>n</em>M</tt> is the number of months.</li>
|
|
<li><tt><em>n</em>D</tt> is the number of days.</li>
|
|
<li><tt>T</tt> is the date and time separator.</li>
|
|
<li><tt><em>n</em>H</tt> is the number of hours.</li>
|
|
<li><tt><em>n</em>M</tt> is the number of minutes.</li>
|
|
<li><tt><em>n</em>S</tt> is the number of seconds. The number of seconds can include decimal digits to arbitrary precision.</li>
|
|
</ul>
|
|
<p>For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, set the expiration time to <tt>P1Y2M3DT10H30M</tt>. Typically, you configure a message timestamp for about 10 to 30 minutes. For an expiration of 10 minutes, specify <tt>P0Y0M0DT0H10M0S</tt>.</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 on the client with 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 locations:</p>
|
|
<ul>
|
|
<li>Click <strong>Security Extensions --> 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 --> 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 may 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 digitally sign the request parts:</p>
|
|
|
|
<ol>
|
|
<li><p>Click the <strong>Port Binding</strong> tab.</p></li>
|
|
|
|
<li><p>Expand <strong>Security Request Sender Binding Configuration --> Signing Information</strong>.</p></li>
|
|
|
|
<li><p>Select <strong>Edit</strong> to view the signing information. The following table describes the purpose of this information. 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.</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> element. The signing of the DigestValue binds resource content to the signer key. The algorithm selected for the client request sender configuration must match the algorithm selected in the server request receiver 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 client request sender configuration must match the algorithm selected in the server request receiver configuration.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Signing key name</strong></td>
|
|
<td>The signing key name represents the key entry associated with the signing key locator. The key entry refers to an alias of the key (which is found in the key store or wherever the certificates are stored based upon the key locator implementation) that is used to sign the request.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Signing key locator</strong></td>
|
|
<td>The signing key locator represents a reference to a key locator implementation that locates the correct key store where the alias and certificate reside. For more information on configuring key locators, see <a href="wsseccfkeyloc.htm">Configuring key locators</a>.</td>
|
|
</tr>
|
|
</table><p></p></li>
|
|
|
|
<li><p>Save the file.</p></li>
|
|
</ol>
|
|
|
|
</body>
|
|
</html>
|
|
|