219 lines
11 KiB
HTML
219 lines
11 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.<br>NameCallback</li>
|
|
<li>javax.security.auth.callback.<br>PasswordCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.callback.<br>BinaryTokenCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.callback.<br>XMLTokenReceiverCallback</li>
|
|
<li>com.ibm.wsspi.wssecurity.auth.callback.<br>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.<br>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>
|
|
<p><strong>Note: </strong>Examples may be wrapped for display purposes.</p>
|
|
</body>
|
|
</html>
|
|
|