ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzamy_5.4.0.1/50/sec/secltpa.htm

66 lines
3.5 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>Lightweight Third Party Authentication</title>
</head>
<BODY>
<!-- Java sync-link -->
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
<h5><a name="secltpa"></a>Lightweight Third Party Authentication</h5>
<p>Lightweight Third Party Authentication (LTPA) is intended for distributed, multiple application server and machine environments. The LTPA protocol enables WebSphere Application Server - Express to provide security in a distributed environment, using cryptography. Application servers distributed in multiple nodes and cells can securely communicate using this protocol.</p>
<p>LTPA also provides the single sign-on (SSO) feature. SSO allows users to be authenticated once in a DNS domain, without being prompted for authentication information every time they access a resource. This protocol uses cryptographic keys (LTPA keys) to encrypt and decrypt user data that is passed between the servers. These keys must be shared between the different cells for the resources in one cell to access resources in other cells (this assumes all the cells involved use the same LDAP or custom registry).</p>
<p>When you use LTPA, a token is created, which is signed by the keys. The token contains user information and an expiration time. Because of this, the LTPA token is time-sensitive. All product servers that participate in a protection domain must have synchronized time, date, and time zone. If not, LTPA tokens appear to be prematurely expired and cause authentication or validation failures.</p>
<p>This LTPA token is then passed to other servers (in the same cell or in a different cell) either through cookies (for Web resources when SSO is enabled) or through the authentication layer. If the receiving server or servers share the same keys as the originating server, the token can be decrypted to obtain the user information, validated to make sure that it has not expired and that the user information in the token is valid in its registry. Upon successful validation, resources in the receiving servers can be accessed.</p>
<p>All WebSphere Application Server - Express processes in a cell share the same set of keys. If keys need to be shared between different cells, they need to be exported from one cell and imported to the other. For security purposes the keys that are exported are encrypted with a user-defined password. This same password is required when keys are imported into another cell.</p>
<p>LTPA requires that the configured user registry is a central, shared repository.</p>
<p>This table summarizes the authentication mechanism capabilities and user registries with which LTPA can work:</p>
<table border="1" cellpadding="3">
<!-- cols="10 20 10 20 20 20 " width="page" -->
<tr>
<th>&nbsp;</th>
<th>Forwardable credentials</th>
<th>SSO</th>
<th>LocalOS User Registry</th>
<th>LDAP User Registry</th>
<th>Custom User Registry</th>
</tr>
<tr align="center">
<td><strong>SWAM</strong></td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr align="center">
<td><strong>LTPA</strong></td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>
<p><strong>Note:</strong> For LTPA, the LocalOS user registry must be centrally managed so that the users and groups are the same, regardless of the machine.</p>
</body>
</html>