Single sign-on
With SSO support, Web users can authenticate once when accessing both WAS resources, such as...
- HTML
- JavaServer Pages
- servlets
- enterprise beans
- Lotus Domino resources, such as documents in a Domino database
...and resources in multiple WAS domains.
Application servers distributed in multiple nodes and cells can securely communicate using the LTPA protocol which encrypts, digitally signs, and securely transmits authentication-related data, and later decrypts and verifies signatures.
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 or to a Domino server. This authentication is accomplished by configuring WAS servers and the Domino servers to share authentication information.
Without logging in again, Web users can access other WAS or Domino servers in the same DNS domain that are enabled for SSO.
Prerequisites and conditions
To use SSO between WAS servers or between WAS and a Domino servers, applications must meet the following prerequisites...
- 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 Domino server or WAS on a host that is part of the mycompany.com domain, for example,...
a.mycompany.com
b.mycompany.com
- 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 WAS servers, a standalone custom registry. Domino servers do not support standalone custom registries, but you can use a Domino-supported registry as a standalone custom registry within WAS.
You can use a Domino directory that is configured for LDAP access or other LDAP directories for the registry. The LDAP directory product must have WebSphere Application Server 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 standalone 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 LDAP referrals to connect more than one directory together is not supported. Using multiple Domino directory assistance documents to access multiple directories also is not supported.
- Enable HTTP cookies in browsers because the authentication information that is 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.
- You can share authentication information across multiple Domino domains.
- For WAS:
- WAS V3.5 or later for all platforms are supported.
- You can use any HTTP Web server that is supported by WebSphere Application Server.
- You can share authentication information across multiple product administrative domains.
- Basic authentication (user ID and password) using the basic and form-login mechanisms is supported.
- By default, WAS does a case-sensitive comparison for authorization. This comparison implies that a user who is authenticated by Domino matches the entry exactly (including the base distinguished name) in the authorization table. If case sensitivity is not considered for the authorization, enable the Ignore Case property in the LDAP user registry settings.
Sub-topics
Single sign-on for HTTP requests using SPNEGO
Kerberos configuration requirements for SPNEGO TAI
Global single sign-on principal mapping
Related tasks
Implementing single sign-on to minimize Web user authentications
Configure single sign-on capability with Tivoli Access Manager or WebSEAL