+

Search Tips   |   Advanced Search

Single sign-on for authentication using LTPA cookies

With single sign-on (SSO) support, web users can authenticate once when accessing WebSphere Application Server resources, such as HTML, JSP files, servlets, enterprise beans. Application servers distributed in multiple nodes and cells can securely communicate using the LTPA protocol. LTPA is intended for distributed, multiple application server and machine environments. 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. LTPA also provides the SSO feature wherein a user is required to authenticate only once in a DNS domain and can access resources in other WAS cells without getting prompted. Web users can authenticate once to a WAS. This authentication is accomplished by configuring WAS appservers to share authentication information. Without logging in again, web users can access other appservers in the same DNS domain enabled for SSO. We can enable SSO among appservers by configuring SSO for WAS. To enable SSO between application servers configure SSO for both WAS.


Prerequisites

  1. Verify that all servers are configured as part of the same DNS domain. The realm names on each system in the DNS domain are case sensitive and must match identically. For example, if the DNS domain is specified as mycompany.com, then SSO is effective with any WAS on a host that is part of the mycompany.com domain, for example, a.mycompany.com and b.mycompany.com. Cross-domain SSO is not supported, for example z.AAAcompany.com and w.BBBcompany.com - where the DNS domains are different.

  2. Verify that all servers share the same registry. This registry can be either a supported LDAP directory server or, if SSO is configured between two appservers, a stand-alone custom registry.

  3. Define all users in a single LDAP directory.

  4. Enable HTTP cookies in browsers. Authentication information generated by the server is transported to the browser in a cookie. The cookie is used to propagate the authentication information for the user to other servers, exempting the user from entering the authentication information for every request to a different server. Use any HTTP web server supported by WAS.

  5. We can share authentication information across multiple product administrative domains.

  6. Basic authentication (user ID and password) is supported. Form-login mechanisms for web applications require that SSO is enabled.

  7. By default, WAS does a case-sensitive comparison for authorization. The registry entry must match the entry exactly (including the base distinguished name) in the WAS authorization table. If case sensitivity is not considered for the authorization, enable the "Ignore Case" property in the LDAP user registry settings.


Related:

  • Single sign-on for authentication
  • Use a WAS API to achieve downstream web single sign-on with an LtpaToken2 cookie
  • Single sign-on for HTTP requests using SPNEGO web authentication
  • Create a single sign-on for HTTP requests using SPNEGO Web authentication