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

103 lines
4.2 KiB
HTML
Raw Permalink 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>Verification Header Handler</title>
</head>
<BODY>
<!-- Java sync-link -->
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
<h6><A NAME="wsspscvh">Verification Header Handler</A></h6>
<p>The Verification Header Handler (VHH) validates a digital signature header in a SOAP envelope. You
can customize its configuration by using a configuration file where you specify:</p>
<ul>
<li>A verification policy</li>
<li>The certificate path</li>
<li>Logging files to record verified messages</li>
</ul>
<p>There are two signature configuration files:</p>
<ul>
<li>/QIBM/UserData/WebASE/ASE5/<em>instance_name</em>/installedApps/<em>node_name</em>/<br>
<em>ear_file_name</em>/soapsec.war/conf/sv-ver-config.xml</li>
<li> /QIBM/UserData/WebASE/ASE5/<em>instance_name</em>/installedApps/<em>node_name</em>/<br>
<em>ear_file_name</em>/soapsec.war/conf/cl-ver-config.xml</li>
</ul>
<p>where <em>instance_name</em> is the name of the root directory for your instance of WebSphere
Application Server.</p>
<p>Here is an explanation of each configuration element in the Verification Header:</p>
<ul>
<li><strong>AllowedAlgorithms</strong><br>
All the algorithms supported by this Verification Header Handler must be listed in this element.
Algorithms other than these cannot be used in SOAP-SEC:Signature header. The current implementation
supports all required algorithms in the XML Signature specification, except for SHA1-MAC.</li>
<li><strong>RequiredAuthenticatedParts</strong><br>
This section specifies what parts of SOAP message need to be authenticated through the
SOAP-SEC:Signature header. Currently two values are supported for the part attribute:
<ul>
<li>When part=&quot;root&quot;, the whole envelope must be signed through the
enveloped-signature transform.</li>
<li>When part=&quot;body&quot;, the SOAP-ENV:Body element in the SOAP envelope must be
referenced by one of the reference elements in the signature.</li>
</ul>
In the future, part=&quot;&quot; allows an attachment to be specified. If the specified parts are
not authenticated through the signature header entry, verification fails.
</li>
<li><strong>DefaultVerificationKeys</strong><br>
When KeyInfo is missing in the signature, the content of this element is used as a part of the
signature. When communicating parties know the identity of each other, the default KeyInfo can be used
to reduce the communication data volume.</li>
<li><strong>Log</strong><br>
Specifies the logging behavior. These versions of logging exist:
<ul>
<li>When target=&quot;all&quot;, all verification attempts are logged.</li>
<li>When target=&quot;success&quot;, only successful verification are logged.</li>
<li>When target=&quot;fail&quot;, only unsuccessful verification are logged.</li>
</ul>
<p><strong>Note:</strong> You can specify multiple LogFile elements.</p>
<p>This example illustrates how to specify logging:</p>
<pre>
&lt;Log&gt;
&lt;SOAPDSigLogger class=&lt;com.ibm.xml.soap.security.dsig.SOAPDSigLoggerImpl&quot;&gt;
&lt;LogFile target=&quot;all&quot; path=&quot;SOAPVHH-all.log&quot; append=&quot;yes&quot;/&gt;
&lt;/SOAPDSigLogger&gt;
&lt;SOAPDSigLogger class=&quot;com.ibm.xml.soap.security.dsig.SOAPDSigLoggerImpl&quot;&gt;
&lt;LogFile target=&quot;fail&quot; path=&quot;SOAPVHH-fail.log&quot; append=&quot;yes&quot;/&gt;
&lt;/SOAPDSigLogger&gt;
&lt;/Log&gt;
</pre>
</li>
<li><strong>PKIXParameters</strong><br>
Currently, the Verification Header Handler supports X.509/PKIX certificates only (no HMAC, no PGP,
and so forth). The policies for PKIX certificate verification are specified in this element. This is a
straightforward mapping of the Java<sup>(TM)</sup> CertPath API. Not all of the entries are meaningful
in this initial release. The current implementation only allows the use of keystore as the means of
specifying trusted root.</li>
</ul>
<p><strong>Note: </strong>Examples may be wrapped for display purposes.</p>
</body>
</html>