Single sign-on for authentication using LTPA cookies

With single sign-on (SSO) support, web users can authenticate once when accessing resources in multiple WebSphere Application Server domains. 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 supports encrypting, digitally signing, and securely transmitting authentication-related data.

Prerequisites and conditions

To take advantage of support for SSO between WAS appservers, or between WAS and a Domino server, applications must meet the following prerequisites and conditions:

• Configure all servers 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 myco.com, then SSO is effective with any Domino server or WAS on a host that is part of the myco.com domain, for example, a.myco.com and b.myco.com. Cross-domain SSO is not supported, for example a.myco.com and b.yourco.com, where the DNS domains are different.

• Verify that all servers share the same registry.

  Either a supported LDAP directory server or, if SSO is configured between two WAS appservers, a stand-alone custom registry. Domino servers do not support stand-alone custom registries, but we can use a Domino-supported registry as a stand-alone custom registry within WAS.

  We can use a Domino directory configured for LDAP access or other LDAP directories for the registry. The LDAP directory product must have WAS support. Supported products include both Domino and LDAP servers, such as IBM Tivoli Directory Server. Regardless of the choice to use an LDAP or a stand-alone custom registry, the SSO configuration is the same. The difference is in the configuration of the registry.

• Define all users in a single LDAP directory.

  Using multiple Domino directory assistance documents to access multiple directories also is not supported.

• 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.

• For a Domino server:

  • Domino Release 6.5.4 for iSeries and other platforms are supported.

  • A Lotus Notes client Release 5.0.5 or later is required for configuring the Domino server for SSO.

  • We can share authentication information across multiple Domino domains.

• For WAS:

  • We can use any support HTTP web server.

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

  • Basic authentication (user ID and password) using the basic and form-login mechanisms is supported.

    Form-login mechanisms for web applications require that SSO is enabled.

  • By default, WAS does a case-sensitive comparison for authorization.

    A user who is authenticated by Domino 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 concepts

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