162 lines
10 KiB
HTML
162 lines
10 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 server for Web services identity assertion authentication</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h6><a name="wsseccfidautsv"></a>Configure the server for Web services identity assertion authentication</h6>
|
|
|
|
<p>Use this task to configure identity assertion authentication. The purpose of identity assertion is to assert the authenticated identity of the originating client from a Web service to a downstream Web service. Do not attempt to configure identity assertion from a pure client.</p>
|
|
|
|
<p>For the downstream Web service to accept the identity of the originating client (user name only), you must supply a special trusted BasicAuth credential that the downstream Web service trusts and can authenticate successfully. You must specify the user ID of the special BasicAuth credential in a trusted ID evaluator on the downstream Web service configuration. For more information on trusted ID evaluators,
|
|
see <a href="wssectrustid.htm">Trusted ID evaluators</a>.</p>
|
|
|
|
<p>The server side passes the special BasicAuth credential into the trusted ID evaluator, which returns true or false that this ID is trusted. After it is trusted, the user name of the client is mapped to the credential, which is used for authorization.</p>
|
|
|
|
<p>Perform these steps to configure the server for identity assertion authentication:</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 the <strong>Request Receiver Service Configuration Details --> Login Config</strong> settings.</p></li>
|
|
|
|
<li><p>Select <strong>IDAssertion</strong> to authenticate the client using the identity assertion data provided. This user ID of the client must be in the target user registry configured in WebSphere Application Server - Express global security. You can select global security in the Administrative Console by clicking <strong>Security --> Global security</strong>.</p>
|
|
|
|
<p><strong>Note:</strong> You can select multiple login configurations, which means that different types of security information can be received at the server. The order in which the login configurations are added decides the order in which they are processed when a request is received. This can cause problems if you have multiple login configurations added that have security tokens in common. For example, ID assertion contains a BasicAuth token, which is the token that is being trusted. For ID assertion to work properly, you must list ID assertion ahead of BasicAuth in the list or BasicAuth processing overrides ID assertion processing.</p></li>
|
|
|
|
<li><p>Expand the <strong>IDAssertion</strong> section. You need to select both the <strong>ID Type</strong> and <strong>Trust Mode</strong>:</p>
|
|
<ul>
|
|
<li>For <strong>ID Type</strong>, the options are:
|
|
<ul>
|
|
<li><strong>Username</strong></li>
|
|
<li><strong>DN</strong> (distinguished name)</li>
|
|
<li><strong>X509Certificate</strong></li>
|
|
</ul>
|
|
<p>These choices are just preferences and are not guaranteed. Most of the time <strong>Username</strong> is used. You must choose the same <strong>ID Type</strong> as the client.</p></li>
|
|
|
|
<li><p>The <strong>Trust Mode</strong> refers to the information sent by the client as the trusted ID. For <strong>Trust Mode</strong>, the options are as follows:</p>
|
|
<ul>
|
|
<li><p>If you select <strong>BasicAuth</strong>, the client sends basic authentication data (user ID and password). This BasicAuth data is authenticated to the configured user registry. After the authentication occurs successfully, the user ID must be part of the trusted ID evaluator trust list.</p></li>
|
|
<li><p>If you select <strong>Signature</strong>, the client signing certificate is sent. This certificate must be mappable to the configured user registry. For <strong>Local OS</strong>, the common name (CN) of the distinguished name (DN) is mapped to a user ID in the registry. For <strong>LDAP</strong>, the DN is mapped to the registry for the ExactDN mode. If it is in the certificateFilter mode, attributes are mapped accordingly. In addition, the user name from the credential generated must be in the Trusted ID Evaluator trust list.</p></li>
|
|
</ul></li>
|
|
</ul></li>
|
|
|
|
<li><p>Save the file.</p></li>
|
|
</ol>
|
|
|
|
<p>Next, perform the following steps in the Web Services Editor to specify how the identity assertion authentication information is validated.</p>
|
|
|
|
<ol>
|
|
<li><p>Click the <strong>Binding Configurations</strong> tab.</p></li>
|
|
|
|
<li><p>Expand the <strong>Request Receiver Binding Configuration Details --> Login Mapping</strong>
|
|
settings.</p></li>
|
|
|
|
<li><p>Click <strong>Edit</strong> to view the login mapping information. Click <strong>Add</strong> to add new login mapping information. The login mapping dialog displays.</p></li>
|
|
|
|
<li><p>Select or enter the following information:</p>
|
|
|
|
<table border="1" cellpadding="3" cellspacing="0">
|
|
<tr valign="top">
|
|
<th>Name</th>
|
|
<th>Purpose</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Authentication method</strong></td>
|
|
<td>The authentication method specifies the type of authentication that occurs. Select <strong>IDAssertion</strong> to use identity assertion authentication.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Configuration name</strong></td>
|
|
<td>This specifies the JAAS login configuration name. For the IDAssertion authentication method, enter <tt>system.wssecurity.IDAssertion</tt> for the Java Authentication and Authorization Service (JAAS) login configuration name.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Use Token value type</strong></td>
|
|
<td>This option determines if you want to specify a custom token type. For the default authentication method selections, you do not need to specify this option.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Token value type URI</strong> and <strong>Token value type local name</strong></td>
|
|
<td>When you select ID assertion, you cannot edit these values. These values are specifically for custom authentication types. For the ID assertion authentication method, you do not need to enter any information in these fields.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Callback Handler Factory Class name</strong></td>
|
|
<td>This class name creates a JAAS CallbackHandler implementation that supports the following callbacks:
|
|
<ul>
|
|
<li>javax.security.auth.callback.NameCallback</li>
|
|
<li>javax.security.auth.callback.PasswordCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.
|
|
callback.BinaryTokenCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.
|
|
callback.XMLTokenReceiverCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.
|
|
callback.PropertyCallback</li>
|
|
</ul>
|
|
<p>For any of the default Authentication methods (BasicAuth, IDAssertion, and Signature), use the
|
|
callback handler factory default implementation. Enter the following class name for any of the default
|
|
authentication methods including IDAssertion: <tt>com.ibm.wsspi.wssecurity.auth.callback.
|
|
WSCallbackHandlerFactoryImpl</tt>. This implementation creates the correct callback handler for the
|
|
default implementations.</p></td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Callback handler factory property name</strong> and <strong>Callback handler factory property value</strong></td>
|
|
<td>This property is used to specify callback handler properties for Custom callback handler factory implementations. The default callback handler factory implemetation does not need any properties to be specified. For ID assertion, you do not need to enter any values for this property.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Login mapping property name</strong> and <strong>Login mapping property value</strong></td>
|
|
<td>This option is used to specify properties for a custom login mapping. For the default implementations including IDAssertion, you do not need to enter any properties for this option.</td>
|
|
</tr>
|
|
</table><p></p></li>
|
|
|
|
<li><p>Expand the <strong>Trusted ID Evaluator</strong> section. Click <strong>Edit</strong> to see a dialog displaying all the trusted ID evaluator information. Specify or enter the following information:</p>
|
|
|
|
<table border="1" cellpadding="3" cellspacing="0">
|
|
<tr valign="top">
|
|
<th>Name</th>
|
|
<th>Purpose</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Class name</strong></td>
|
|
<td>The classname refers to the implementation of the trusted ID evaluator that you want to use. Enter the default implementation as <tt>com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl</tt>. If you want to implement your own trusted ID evaluator, you must implement the com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator interface.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Property name</strong></td>
|
|
<td>The name is the name of this configuration. Enter <tt>BasicIDEvaluator</tt>.</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td><strong>Property value</strong></td>
|
|
<td>The property defines name and value pairs that can be used by the trusted ID evaluator implementation. For the default implementation, the trusted list is defined here. When a request comes in and the trusted ID is verified, the user ID, as it appears in the user registry, must be listed in this property. Specify the property as a name and value pair where the name is <tt>trustedId_<em>n</em></tt>, where <em>n</em> is an integer (starting from 0) and the value is the user ID associated with that name.
|
|
|
|
<p>Here is an example list of the trusted names:</p>
|
|
<ul>
|
|
<li><tt>trustedId_0 = user1</tt></li>
|
|
<li><tt>trustedId_1 = user2</tt></li>
|
|
</ul>
|
|
<p>These values mean that both user1 and user2 are trusted. Both user 1 and user2 must be listed in the configured user registry.</p></td>
|
|
</tr>
|
|
</table><p></p></li>
|
|
|
|
<li><p>Expand the <strong>Trusted ID Evaluator Reference</strong> section. Click <strong>Enable</strong> to add a new entry. The text you enter or the <strong>Trusted ID Evaluator Reference</strong> must be the same as the name entered previously in the <strong>Trusted ID Evaluator</strong> field. Make sure that the name matches exactly because as the information is case sensitive. If an entry is already specified, you can change it by clicking <strong>Edit</strong>.</p></li>
|
|
</ol>
|
|
|
|
</body>
|
|
</html>
|
|
|