WebSphere Application Server V7.0: Concepts ... - IBM Redbooks

The authentication mechanism in WebSphere Application Server typically
collaborates closely with a user registry. When performing authentication, the
user registry is consulted. A successful authentication results in the creation of a
credential, which is the internal representation of a successfully authenticated
client user. The abilities of the credential are determined by the configured
authorization mechanism.
Depending on the type of client, the authentication information is sent by using
different protocols:
► Enterprise Beans clients use CSIv2.
► Web clients use HTTP or HTTPS.
Although WebSphere Application Server provides support for multiple
authentication mechanisms, you can configure only a single active authentication
mechanism at a time. WebSphere Application Server supports the following
authentication mechanisms:
► Lightweight Third Party Authentication (LTPA)
► Kerberos
► Rivest Shamir Adleman (RSA) token authentication
Note: Simple WebSphere Authentication Mechanism (SWAM) is deprecated
in WebSphere Application Server V7.0 and will be removed in a future release.
Lightweight Third-Party Authentication (LTPA)
LTPA is intended for distributed, multiple application server and machine
environments. It supports forwardable credentials and single sign-on (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.
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, date, and
time zone synchronized. If not, LTPA tokens appear prematurely expired and
cause authentication or validation failures. When SSO is enabled, this token is
passed to other servers through cookies for Web resources.
If the receiving servers share the same keys as the originating server, the token
can be decrypted to obtain the user information, which is then validated to make
sure that it has not expired and that 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 of the WebSphere Application Server
processes in a cell (deployment manager, node agents, application servers)
share the same set of keys. If key sharing is required between different cells,
386 WebSphere Application Server V7.0: Concepts, Planning, and Design