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

107 lines
5.6 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>HTTP authentication</title>
</head>
<BODY>
<!-- Java sync-link -->
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
<h6><A NAME="wsspscht">HTTP authentication</A></h6>
<p>There are three options for security when using HTTP as the transport protocol:</p>
<ul>
<li><a href="#httpbasic">HTTP basic authentication</a></li>
<li><a href="#ssl">SOAP on Secure Sockets Layer (SSL) with HTTP basic authentication</a></li>
<li><a href="#sslsoap">SOAP on SSL with SOAP signature</a></li>
</ul>
<a name="httpbasic"></a>
<p><strong>HTTP authentication</strong></p>
<p>Many applications require users to provide identifying information. You can restrict access to data based on the authorization level assigned to users.</p>
<!--<p>Using the Application Assembly tool, you can set authorization levels by assigning roles to HTTP methods and by assigning users to roles. You can then authenticate users, verifying they are authorized to view specific information.</p>-->
<p>The Apache implementation of SOAP has an API to set the user ID/password for HTTP basic authentication.</p>
<a name="ssl"></a>
<p><strong>SOAP on Secure Sockets Layer (SSL) with HTTP basic authentication</strong></p>
To make a request over HTTPS, using the SSL support of Apache SOAP, you need a separate <a href="http://java.sun.com/products/jsse/" target="_">Java Secure Socket Extension (JSSE)</a> <img src="www.gif" width="18" height="15" alt="Link outside Information Center" border="0"> provider. WebSphere Application Server includes the ibmjsse.jar JAR file, which includes these APIs.
<p>The SOAP on SSL scenario is useful for many business-to-business applications because:</p>
<ul>
<li>The data in transit is protected from eavesdropping or forgery by SSL</li>
<li>The server identity is guaranteed by SSL server authentication</li>
<li>The client identity is authenticated through user ID and password, which are encrypted by the SSL transport</li>
</ul>
<p>For example, if an inventory application is configured as a web service, the service provider has these two SOAP service entries:</p>
<ul>
<li>https://a_company.com/inventory/inquiry</li>
<li>https://a_company.com/inventory/update</li>
</ul>
<p>Each SOAP service entry should be deployed as a separate enterprise application (EAR) because each service has a different access control policy, which is that anyone can inquire about the inventory but only the inventory clerks can update the contents.</p>
<p>Perform these steps to enable the SOAP on SSL scenario:</p>
<ol>
<li>Configure the web server (httpd.conf) so that it only allows SSL access to these servlets.</li>
<li>Configure the security role for the RPCRouterServlet in the inquiry services EAR so that the RPCRouterServlet for the inquiry service is accessible by everyone, while the RPCRouterServlet for the 'update' service requires authentication based on the HTTP basic authentication (user ID/password).</li>
</ol>
<p>In this case, the 'update' application does not know the identity of the requester; it only knows that access is granted.</p>
<p><a name="sslsoap"></a></p>
<p><strong>SOAP on SSL with SOAP signature</strong></p>
<p>Applications might need nonrepudiable proof of exchanged messages. One example is a web service that accepts part orders. The business partners establish a form of trust relationship based on public keys. This can be done using the public key infrastructure (PKI) through a third party certificate authority (CA), or by exchanging public keys through a secure channel. The following service is deployed with a signature verification function: <tt>https://a_company.com/partorder</tt>.</p>
<p>Configure signature verification with this information:</p>
<ul>
<li>Scope of signature (indicates the portion of the SOAP envelope that must be authenticated. The default is the content of SOAP-ENV:Body).</li>
<li>Trusted keys or trusted root keys.</li>
<li>Default key to verify signature if no KeyInfo is specified.</li>
<li>Other policies regarding signature validation.</li>
<li>Behavior when signature verification fails.</li>
<li>Additional requirements on signature (as for example, specific requirements on hash/C14N algorithms to be used, timestamp validity, and so forth).</li>
</ul>
<p>If the signature is missing or if signature verification fails, the signature verification function can be configured so that the servlet returns a SOAP fault.</p>
<p>To send part orders to the https://a_company.com/partorder service, the service requester should sign her or his SOAP messages with a signature component. The signature component is initialized using two templates:</p>
<ol>
<li>&lt;ds:SignedInfo&gt; template</li>
<li>&lt;ds:KeyInfo&gt; template</li>
</ol>
<p>The &lt;ds:SignedInfo&gt; template controls:</p>
<ul>
<li>What parts of the SOAP envelope must be signed</li>
<li>What algorithms (canonicalization, transformation, digest, sign) should be used</li>
</ul>
<p>The &lt;ds:KeyInfo&gt; template controls:</p>
<ul>
<li>Whether or not to include the entire certificate chain in &lt;ds:KeyInfo&gt;</li>
<li>Decision to include only certificate and serial number</li>
<li>Public key value</li>
<li>Decision to provide no key information (so that the default key must be used for verification)</li>
</ul>
<p>You can combine the service request with HTTP basic authentication, if necessary.</p>
</body>
</html>