This article describes common problems in configuring single signon between a WebSphere Application Server - Express and a Domino server and suggests possible solutions.
Failure to save the Domino Web SSO Configuration document.
The client must be able to find Domino server documents for the Domino servers that are participating in single signon. The Web SSO Configuration document is encrypted for the servers that you specify, so the home server that is indicated by the client location record must point to a server in the Domino domain where the participating servers reside. This pointer ensures that lookups can find the public keys of the servers.
If you receive a message stating that one or more of the participating Domino servers cannot be found, then those servers cannot decrypt the Web SSO Configuration document or perform single signon.
When the Web SSO Configuration document is saved, the status bar indicates how many public keys were used to encrypt the document by finding the listed servers, authors, and administrators on the document.
Domino server console fails to load the Web SSO Configuration document upon Domino HTTP server startup.
During configuration of single signon, the server document is configured for Multi-Server in the Session Authentication field. The Domino HTTP server tries to find and load a Web SSO Configuration document during startup. The Domino server console reports the following message if a valid document is found and decrypted:
HTTP: Successfully loaded Web SSO Configuration.
If a server cannot load the Web SSO Configuration document, single signon does not work. In this case, a server reports the following message:
HTTP: Error Loading Web SSO configuration. Reverting to single-server session authentication.
Verify that there is only one Web SSO Configuration document in the Web Configurations view of the Domino directory and in the $WebSSOConfigs hidden view. You cannot create more than one document, but you can insert additional documents during replication.
If there is only one Web SSO Configuration document, another condition that can cause the same error message is when the public key of the Server document does not match the public key in the ID file. In this case, attempts to decrypt the Web SSO Configuration document fail and the error message is generated.
This situation can occur when the ID file is created multiple times but the Server document is not updated correctly. Usually, there is an error message displays on the Domino server console stating that the public key does not match the server ID. If this happens, single signon does not work because the document is encrypted with a public key for which the server does not possess the corresponding private key.
To correct a key-mismatch problem, perform the following steps:
Authentication fails when accessing a protected resource.
If a Web user is repeatedly prompted for a user ID and password, single signon is not working because either the Domino or the WebSphere security server is not able to authenticate the user with the Lightweight Directory Access Protocol (LDAP) server. Check the following possibilities:
Verify that the LDAP server is accessible from the Domino server machine. Use the TCP/IP ping utility to check TCP/IP connectivity and to verify that the host machine is running.
Verify that the LDAP user is defined in the LDAP directory. Use the ldapsearch utility to confirm that the user ID exists and that the password is correct. For example, you can run the following command, entered as a single line, from the i5/OS Qshell, a UNIX shell, or a Windows DOS prompt:
ldapsearch -D "cn=John Doe, ou=Rochester, o=IBM, c=US" -w mypassword -h myhost.mycompany.com -p 389 -b "ou=Rochester, o=IBM, c=US" (objectclass=*)
A list of directory entries is expected. Possible error conditions and causes follow:
If you are using the user's short name (or user ID) instead of the distinguished name, verify that the directory entry is configured with the short name. For a Domino directory, this is the Short name/UserID field of the Person document. For other LDAP directories, this is the userid property of the directory entry.
If Domino authentication fails when using an LDAP directory other than Domino directory, verify the configuration settings of the LDAP server in the Directory Assistance document in the Directory Assistance database. Also verify that the Server document refers to the correct Directory Assistance document.
The following LDAP values that are specified in the Directory Assistance document must match the values that are specified for the user registry in the WebSphere administrative domain:
Additionally, the rules that are defined in the Directory Assistance document must refer to the base DN of the directory containing the directory entries of the users.
You can trace Domino server requests to the LDAP server by adding the following line to the server notes.ini file:
webauth_verbose_trace=1
After restarting the Domino server, trace messages displays in the Domino server console as Web users attempt to authenticate to the Domino server.
Authorization fails when accessing a protected resource.
After authenticating successfully, if a Web user is shown an authorization error message, security is not configured correctly.
For Domino databases, verify that the user is defined in the access-control settings for the database. Refer to the Domino Administrative documentation for the correct way to specify the user's DN. For example, for the DN cn=John Doe, ou=Rochester, o=IBM, c=US, the value on the access-control list must be set as John Doe/Rochester/IBM/US.
For resources that are protected by WebSphere Application Server - Express, verify that the security permissions are set correctly. If granting permissions to selected groups, make sure that the user that is attempting to access the resource is a member of the group. For example, you can verify the members of the groups by using the following URL to display the directory contents:
Ldap://myhost.mycompany.com:389/ou=Rochester, o=IBM, c=US??sub
If you have changed the LDAP configuration information (host, port, and base DN) in a WebSphere Application Server - Express administrative domain since the permissions were set, the existing permissions are probably invalid and need to be re-created.
SSO fails when accessing protected resources.
If a Web user is prompted to authenticate with each resource, SSO is not configured correctly. Check the following possibilities:
Both WebSphere Application Server - Express and the Domino server must be configured to use the same LDAP directory. The HTTP cookie that is used for single signon stores the full DN of the user (for example, cn=John Doe, ou=Rochester, o=IBM, c=US) and the domain name system (DNS) domain.
If the Domino Directory is used, define Web users by hierarchical names. For example, update the User name field in the Person document to include names of this format as the first value: John Doe/Rochester/IBM/US.
URLs that are issued to Domino servers and WebSphere Application Server - Express servers that are configured for single signon must specify the full DNS server name, not only the host name or TCP/IP address. For browsers to send cookies to a group of servers, the DNS domain must be included in the cookie, and the DNS domain in the cookie must match the URL. (This requirement means that you cannot use cookies across TCP/IP domains.)
Domino and WebSphere Application Server - Express must be configured to use the same DNS domain. Verify that the DNS domain value is exactly the same, including capitalization. The DNS domain value is found on the Configure Global Security Settings panel of the WebSphere administrative console and in the Web SSO Configuration document of a Domino server. If you make a change to the Domino Web SSO Configuration document, replicate the modified document to all Domino servers that are participating in single signon.
Clustered Domino servers must have the host name populated with the full DNS server name in the Server document for Domino Internet Cluster Manager (ICM) to redirect to cluster members that are using single signon. If this field is not populated, by default, ICM redirects URLs to clustered Web servers by using only the host name. It cannot send the single signon cookie because the DNS domain is not included in the URL.
To correct the problem, perform the following steps: