Single sign-on for authentication
With single sign-on (SSO) support, web users can authenticate once when accessing both WebSphere Application Server resources, such as HTML, JSP files, servlets, enterprise beans, and Lotus Domino resources, such as documents in a Domino database, or accessing resources in multiple WAS domains. There are various ways to accomplish SSO, with the most common in WebSphere using LTPA cookies. LTPA cookies do not require any particular client and allow SSO across different cells provided the registry and LTPA keys are the same. There are other types of SSO, including Simple and Protected GSS-API Negotiation (SPNEGO), which is a way to use the token from a Kerberos login (typically Windows) to authenticate to WAS. This prevents the user from having to type in their userid and passwords again.
In WAS Version 6.1, a trust association interceptor (TAI) that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources was introduced. This function was deprecated In WAS 7.0. SPNEGO web authentication has taken its place to provide dynamic reload of the SPNEGO filters and to enable fallback to the application login method.
TAIs are also a form of single sign-on when used in combination with a Proxy server that does the front-end authentication. The TAI allows the credentials to flow to WebSphere from the Proxy server and to be used to log in without the need to reauthenticate the user.
Subtopics
- Single sign-on for authentication using LTPA cookies
- Use a WAS API to achieve downstream web single sign-on with an LtpaToken2 cookie
- (iSeries) Enterprise Identity Mapping
- Global single sign-on principal mapping for authentication
Related:
Single sign-on for HTTP requests using SPNEGO TAI (deprecated) Single sign-on for HTTP requests using SPNEGO web authentication Create a single sign-on for HTTP requests using SPNEGO Web authentication Implement single sign-on to minimize web user authentications Configure SSO capability with ISAM WebSEAL