51 lines
5.5 KiB
HTML
51 lines
5.5 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>Identity authentication method for Web services</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h6><a name="wssecidauth"></a>Identity authentication method for Web services</h6>
|
||
|
|
|
||
|
|
<p>When using the Identity Assertion (IDAssertion)authentication method, the security token generated is a <wsse:UsernameToken> element that contains a <wsse:Username> element. On the request sender side, a callback handler is invoked to generate the security token. On the request receiver side, the security token is validated. These two operations, token generation and token validation, are described in the following topics.</p>
|
||
|
|
|
||
|
|
<p><strong>Identity Assertion token validation</strong></p>
|
||
|
|
|
||
|
|
<p>The request receiver retrieves the IDAssertion security token from the Simple Object Access Protocol (SOAP) message and validates it using a Java Authentication and Authorization Service (JAAS) login module. With identity assertion, special processing is required to establish trust before asserting the identity as the established identity of the thread of execution. This special processing misdefined by the <IDAssertion> element in the deployment descriptor file, ibm-webservices-ext.xmi. If all the validation checks are successful,the asserted identity is set as the identity of the thread of execution. If the validation fails, the request is rejected with a SOAP fault exception.</p>
|
||
|
|
|
||
|
|
<p>The JAAS login configuration is specified in the <LoginMapping> element of the bindings file. There are default bindings specified in the ws-security.xml file. However, you can override these bindings using the application specific ibm-webservices-bnd.xmi file. The configuration information consists of a CallbackHandlerFactory and a ConfigName. The CallbackHandlerFactory specifies the name of a class that is used for creating the JAAS CallbackHandler object. WebSphere Application Server - Express provides the com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl CallbackHandlerFactory implementation. The ConfigName specifies a JAAS configuration name entry. WebSphere Application Server - Express searches the security.xml file for a matching configuration name entry. If a match is not found it searches the wsjaas.conf file. WebSphere Application Server - Express provides the system.wssecurity.IDAssertion default configuration entry, which is suitable for the identity assertion authentication method.</p>
|
||
|
|
|
||
|
|
<p>The <IDAssertion> element in the ibm-webservices-ext.xmi deployment descriptor file specifies the special processing required when using the identity assertion authentication method. The <IDAssertion> element is composed of two sub-elements:<IDType> and <TrustMode>.</p>
|
||
|
|
|
||
|
|
<p>The <IDType> element specifies the method for asserting the identity. The supported values for asserting the identity are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Username</li>
|
||
|
|
<li>Distinguished Name (DN)</li>
|
||
|
|
<li>X509Certificate</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>When <IDType> is <tt>username</tt>, a username token (for example, Bob) is provided. This user name is mapped to a user in the user registry and is the asserted identity after successful trust validation. When the <IDType> is <tt>DN</tt>, a user name token containing a distinguished name is provided (for example, cn=Bob Smith, o=ibm, c=us). This DN is mapped to a user in the user registry and this user is the asserted identity after successful trust validation. When the<IDType> is <tt>X509Certificate</tt>, a binary security token containing an X509certificate is provided and the SubjectDN from the certificate (for example, cn=Bob Smith, o=ibm, c=us) is extracted. This Subject DN is mapped to a user in the user registry and this user is the asserted identity after successful trust validation.</p>
|
||
|
|
|
||
|
|
<p>The <TrustMode> element specifies how the trust authority, or asserting authority, provides trust information. The supported values are:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Signature</li>
|
||
|
|
<li>BasicAuth</li>
|
||
|
|
<li>(No value specified)</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>When <TrustMode> is <tt>Signature</tt>, the signature is validated. Then, the signer (for example, cn=IBM Authority, o=ibm, c=us) is mapped to an identity in the user registry (for example, IBMAuthority). To ensure that the asserting authority is trusted, the mapped identity (for example, IBMAuthority) is validated against a list of trusted identities. When the <TrustMode> is
|
||
|
|
<tt>BasicAuth</tt>, there is a user name token with a username and password, which is the user name and password of the asserting authority. The user name and password are validated. If they are successfully validated, that user name (for example, IBMAuthority) is validated against a list of trusted identities. If a value is not specified for <TrustMode>, trust is presumed and additional trust validation is not performed. This type of identity assertion is called <em>presumed trust mode</em>. Use the presumed trust mode only in an environment where the trust is established using some other mechanism.</p>
|
||
|
|
|
||
|
|
<p>If all the validations described previously succeed, the asserted identity (for example, Bob) is set as the identity of the thread of execution. If any of the validations fail, the request is rejected with a SOAP fault exception.</p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|