Multi-server session-based authentication (single sign-on)

Multi-server session-based authentication, also known as single sign-on (SSO), allows Web users to log in once to a Domino® or WebSphere® server, and then access any other Domino® or WebSphere® servers in the same DNS domain that are enabled for single sign-on (SSO) without having to log in again.

About this task

User Web browsers must have cookies enabled since the authentication token that is generated by the server is sent to the browser in a cookie.

You set this up by doing the following:

  • Creating a domain-wide configuration document -- the Web SSO Configuration document -- in the Domino® Directory. (You can have multiple Web SSO Configuration documents in a Domino® Domain or directory.) If you are using Internet sites, you can create SSO configuration documents for each Internet Sites (however, not all protocols honor Internet Site configurations).
  • Enabling the Multi-servers (SSO) option for session-based authentication in a Web Site document or in the Server document.

You can enable single sign-on across multiple Domino® domains.

The SSO feature makes logging in and using multiple servers in a mixed environment easier for users. Use the following list to configure your Domino® environment to ensure that your SSO configuration is successful.

General issues

About this task

  • It is important that all servers participating in an SSO group must use the same mechanism for configuring Internet access. They must either all use Internet Site documents, or they must all have Internet access configured in the Server document.
  • The DNS domain that applies to the participating SSO servers is specified in the SSO configuration document. URLs issued to servers configured for single sign-on must specify the full DNS server name, not the host name or IP address. For browsers to be able to send cookies to a group of servers, the DNS domain is included in the cookie (as specified by the configuration), and the DNS domain in the cookie must match the server URL. This is why cookies cannot be used across TCP/IP domains.
  • Clustered servers must have the full DNS server name in the host name field of the Web Site or Server document. This enables the Internet Cluster Manager (ICM) to redirect to cluster members using SSO. If the DNS server host name is not there, ICM will redirect URLs to clustered Web servers with only the TCP/IP host name, by default, and will not be able to send the cookie because the DNS domain is not included in the URL.
  • If you enable Internet Sites in the Server document, any existing SSO configuration is automatically disabled.

WebSphere® issues

About this task

  • WebSphere® and Domino® do not need to be configured for the same LDAP directory; however, if WebSphere® and Domino® will not share the same directory, you likely will have a multi-identity problem to plan for and address.
  • Websphere cannot use Domino® LTPA tokens. To include Domino® and WebSphere® in the same LTPA group, you must export the LTPA token from WebSphere® and import it into Domino®.
  • If you have imported WebSphere® keys into your Domino® SSO configuration for interoperability with WebSphere®, then you cannot specify an SSO idle timeout. WebSphere® servers do not honor an idle timeout.
  • If the group of servers participating in single sign-on includes WebSphere® servers that use a Domino® LDAP directory, users with flat names in that directory cannot use SSO (if the participating servers are all Domino®, then SSO will work with flat user names).