WAS v8.5 > Secure applications > Authenticate users > Select an authentication mechanismLTPA
LTPA is intended for distributed, multiple application server and machine environments. LTPA supports forwardable credentials and SSO. LTPA can support security in a distributed environment through cryptography. This support permits LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and later decrypt and verify the signature.
Application servers can securely communicate using the LTPA protocol. It also provides the SSO feature wherein a user is required to authenticate only once in a DNS domain and can access resources in other WebSphere Application Server cells without getting prompted. The realm names on each system in the DNS domain are case sensitive and must match identically.
For UNIX local OS, the realm name is the same as the host name. For Windows local OS, the realm name is the domain name, if a domain is in use or the realm name is the machine name.
For the LDAP, the realm name is the host:port value of the LDAP server.
The LTPA protocol uses cryptographic keys to encrypt and decrypt user data that passes between the servers. These keys must 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 that participate in a protection domain must have their time and date synchronized. If not, LTPA tokens appear prematurely expired and cause authentication or validation failures. Coordinated Universal Time (UTC) is used by default, and all other machines must have the same UTC time.
This token passes to other servers, in the same cell or in a different cell through cookies, for web resources when SSO is enabled, or through the authentication protocol layer 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 verify 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.
Each server must have valid credentials. When the credentials expire, the server is required to communicate to the user registry to authenticate. User registry outages can cause server processes to hang, requiring them to be restarted to recover. Extending the time the LTPA token remains cached reduces this risk, but does present a slightly increased security risk to be considered when defining your security policies.
All of the WAS processes in a cell 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 random generated key and a user-defined password is used to protect the keys. This same password is needed when importing the keys into another cell. The password is only used to protect the keys and is not used to generate the keys.
WAS supports the LTPA, Kerberos and SWAM protocols. SWAM is deprecated in WAS v8.5 and will be removed in a future release.
When security is enabled during profile creation time, LTPA is configured by default.
LTPA requires 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.
Related :
LTPA key sets and key set groups
Trust associations
Single sign-on for authentication using LTPA cookies
Configure the LTPA mechanism
LTPA
Standalone LDAP registry settings
Advanced LDAP user registry settings
Identity assertion to the downstream server
Security: Resources for learning