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.

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.

Creating a Web SSO configuration document
The Web SSO configuration document is a domain-wide configuration document stored in the HCL Domino Directory. This document, which should be replicated to all Domino servers participating in the single sign-on domain, is encrypted for participating servers and administrators, and contains a shared secret key used by servers for verifying user credentials.

Enabling single sign-on and basic authentication
This procedure ensures that a server can participate in single sign-on (SSO). An SSO-enabled server creates single sign-on cookies for users, allowing them to log in to the server and then be able to access other participating servers without having to log in again.

Setting up the Web SSO Configuration document for more than one Domino domain
You can enable servers in your current Domino domain for single-sign on (SSO) with servers in another Domino domain, by setting up both domains to use the same key information.

Configuring user name mapping in the SSO LTPA token
The LTPA token that is created to authenticate users for single sign-on includes the name of the user who has been authenticated. When HCL Domino creates an LTPA token, it places the Domino distinguished name in the token by default. If a IBM® WebSphere Application Server server obtains the token from a user trying to access the server, the Websphere server must be able to recognize this name format. If it does not, the token is ignored, single sign-on fails, and the user is prompted to log in again.

Caching Internet password changes for SSO
When Web users change their Internet passwords, the HCL Domino HTTP server remembers the new Internet password in its cache. Caching is required because it can take some time for the password change to take effect, as the change must be processed by the Domino administration server and replicated throughout the Domino environment.

Setting up Windows single sign-on for Web clients
You can set up a Domino Web server to honor Microsoft™ Windows™ users' Active Directory logon credentials. Web users who are logged on to the Active Directory domain can open applications on the server from a browser without being prompted for a password.

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.

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

Related tasks
Setting up the Web SSO Configuration document for more than one Domino domain
Configuring user name mapping in the SSO LTPA token
Using Notes distinguished names in a remote LDAP directory