126 lines
9.1 KiB
HTML
126 lines
9.1 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 response signing</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h5><a name="wsseccfsignsvres"></a>Configure the Web services server for response signing</h5>
|
|
|
|
<p>This task provides the steps needed configure the server for response signing. Use these steps to modify the extensions to indicate which parts of the response that you want to sign. Also, use the steps to configure the bindings to indicate how the parts of the response are to be signed.</p>
|
|
|
|
<p>Perform the following steps in the WebSphere Development Studio Client for iSeries to configure the security extensions for the parts of the Simple Object Access Protocol (SOAP) message that you want to digitally sign:</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 <strong>Response Sender Service Configuration Details --> 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>You can choose this if <strong>Add Created Time Stamp</strong> is selected and configured.</p></li>
|
|
|
|
<li><p><strong>Securitytoken</strong>
|
|
<br>If security token is selected, the authentication information is added to the message.</p></li>
|
|
</ul></li>
|
|
|
|
<li><p>Expand the <strong>Add Created Time Stamp</strong> section. Select this if you want a time stamp added to the message. Also, you can specify an expiration time for the time stamp, which 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>Repeat these steps for the response receiver configuration section. The client response receiver validates the parts of the response signed by the server. Because the response receiver must validate the message signed by the server, the <strong>Response Receiver Configuration</strong> section requires that you configure integrity. Refer to <a href="wsseccfsignclres.htm">Configure the client for response digital signature verification</a> for more information.</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 --> 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>. 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 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 bindings that are needed to sign the response parts:</p>
|
|
|
|
<ol>
|
|
<li><p>Click the <strong>Binding Configurations</strong> tab.</p></li>
|
|
|
|
<li><p>Expand <strong>Response Sender Binding Configuration Details --> Signing Information</strong>.</p></li>
|
|
|
|
<li><p>Click <strong>Edit</strong> to view the signing information. The signing information dialog displays.</p></li>
|
|
|
|
<li><p>Select or enter the information that is described in the following table. 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 same algorithm used here should also be used on the client response receiver. The algorithm selected for the server response sender configuration must match the algorithm selected in the client response receiver 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 response sender configuration must match the algorithm selected in the client response 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 server response sender configuration must match the algorithm selected in the client response 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>
|
|
|