Lightweight Third Party Authentication
Overview
Lightweight Third Party Authentication encrypts, digitally signs, and securely transmits credentials between machines, supporting single signon between appservers.
The LTPA protocol enables the WebSphere Application Server to provide security in a distributed environment using cryptography. Application servers distributed in multiple nodes and cells can securely communicate using this protocol. It also provides the single signon (SSO) feature wherein a user is required to authenticate only once in a domain name system (DNS) domain and can access resources in other WAS cells without getting prompted. The realm names on each system in the SSO domain are case sensitive and must match identically. For local OS on the Windows platform, the realm name is the domain name, if a domain is in use, or the machine name. On the UNIX platform, the realm name is the same as the host name. For LDAP, the realm name is the host:port of the LDAP server.
The LTPA protocol uses cryptographic keys (LTPA keys) to encrypt and decrypt user data that passes between the servers. These keys need to be shared between the different cells for the resources in one cell to access resources in other cells (assuming that all the cells involved use the same LDAP or custom registry).
When using LTPA, a token is created with the user information and an expiration time and is signed by the keys. The LTPA token is time sensitive. All product servers participating in a protection domain must have their time, date, and time zone synchronized. If not, LTPA tokens appear prematurely expired and cause authentication or validation failures. This token passes 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 (Security Authentication Service (SAS) or Common Secure Interoperability V2 (CSIv2) for enterprise beans). If the receiving servers share the same keys as the originating server, the token can be decrypted to obtain the user information, which then is validated to make sure it has not expired and the user information in the token is valid in its registry. On successful validation, the resources in the receiving servers are accessible after the authorization check.
All the WAS processes in a cell (cell, nodes, appservers) share the same set of keys. If key sharing is required between different cells, export them from one cell and import them to the other. For security purposes, the exported keys are encrypted with a user-defined password. This same password is needed when importing the keys into another cell.
WAS, Network Deployment supports both the LTPA and the Integrated Cryptographic Services Facility (ICSF) protocols. When security is enabled for the first time in WAS Network Deployment with LTPA, configuring LTPA is normally the initial step performed.
LTPA requires that the configured user registry be a centrally shared repository such as LDAP or a Windows domain type registry so that users and groups are the same regardless of the machine.
The following table summarizes the authentication mechanism capabilities and user registries with which LTPA can work.
| Forwardable Credentials | SSO | LocalOS User Registry | LDAP User Registry | Custom User Registry | |
|---|---|---|---|---|---|
| LTPA | Yes | Yes | Yes | Yes | Yes |
| ICSF | Yes | Yes | Yes | Yes | Yes |
Trust Associations
Single Signon
Configuring LTPA
Supported directory services
LTPA settings
LDAP settings
LDAP advanced settings
Identity assertion
Security: Resources for learning