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.

Checklist for enabling single sign-on

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

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

  See the multi-identity section (probably this would be the topic on configuring LTPA user names, as well as the topic that covers the DA feature "Attribute to be used as Notes distinguished name" ).

• Websphere configurations support two different formats of SSO LTPA cookies. One cookie has a name "LtpaToken", and the other cookie format is named "LtpaToken2". Domino SSO supports the "LtpaToken" cookie only, therefore WebSphere must be configured to issue the correct format cookie in order for SSO to work between WebSphere and Domino.
• 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).

Configuring user name mapping in the SSO LTPA token
Using Notes distinguished names in a remote LDAP directory
Distinguished Name syntax in multiple-directory environments
Session-based name-and-password authentication for Web clients
Setting up Domino to work with other Web servers

Glossary