Single sign-on for authentication
With SSO support, Web users can authenticate once when accessing WAS and non-WAS resources, including...
- HTML
- JSPs
- servlets
- enterprise beans
- Domino database
- resources in multiple WAS domains
The most common way to enable SSO in WebSphere is by using LTPA cookies, which do not require any particular client, and allow SSO across different cells providing the registry and LTPA keys are the same.
There are other flavors of SSO, including 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.
WAS V6.1 introduced trust association interceptors that use SPNEGO to securely negotiate and authenticate HTTP requests for secured resources was introduced. In WAS 7.0, this function is now deprecated. 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 login without the need to re-authenticate the user.
Subtopics
Single sign-on for authentication using LTPA cookies
Global single sign-on principal mapping for authentication
Related concepts
Single sign-on for HTTP requests using SPNEGO TAI (deprecated)
Single sign-on for HTTP requests using SPNEGO Web authentication
Related tasks
Create a single sign-on for HTTP requests using SPNEGO Web authentication
Implementing single sign-on to minimize Web user authentications
Set single sign-on capability with TAM or WebSEAL