User Naming for SSO

One of the most important items to consider when designing a Domino and WebSphere SSO configuration is how users will be named, or, more specifically , how the user entries in the user directory will be named. A user name is the primary data involved in authentication and authorization mechanisms. For authentication, a user name supplied by the user either via a login prompt (for basic authentication) or via a client certificate (for SSL client certificate authentication) is validated against the user registry. The following user name issues often arise when designing SSO applications:

Uniqueness . Obviously, user names must uniquely represent clients . This becomes more difficult as the number of users increase.
Format . Users may have to specify the user name in a certain format depending on which HTTP server is used.
Ease of Use . Users want a simple name format to use and remember.
Legacy User Names . Some existing user name formats may not fit those acceptable for SSO.

For basic authentication, the format of the user name that may be specified in the login prompt depends on who (Domino or WebSphere) is doing the authentication and the directory configuration being used. If the Domino HTTP server is handling the basic authentication, it will validate the user name and password against the Domino address book and any LDAP directories configured as extensions to the address book via a Directory Assistance database. If WAS is performing the basic authentication, it will validate against the user registry (which must be an LDAP directory for SSO).

Since both Domino and WebSphere perform user authentication against an LDAP directory, let's review how this is performed more closely. For basic authentication, there are two steps: first, an LDAP search request is issued against the LDAP directory using a "search filter," which is constructed from the name specified in the login prompt; then, if a unique user entry (DN) is returned by the search, an LDAP bind request is made with the DN of the user entry and the password from the login prompt. If the bind request is successful, the user is authenticated. For certificate-based authentication, since the user name in the certificate is validated via the SSL client authentication exchange, only the LDAP search is performed to validate that the user is known to the service, that is, exists in the user registry. We will see that the search filter used in the LDAP user name search can be configured in both Domino and WebSphere. This provides for a wide range of name formats, which can be supported in the login prompt or user certificate.

Domino has its own rules for how user names are authenticated against the address book. The following table summarizes the user name formats accepted by a Domino server using an address book and their corresponding LDAP directory attributes.

Table 12-3. Domino User Name Formats vs. LDAP Directory Attributes

Domino Name and Address Book Fields (Person Document)	LDAP Directory Entry Attributes
First user name (e.g., John Doe/Acme)	Common name (cn)
Alias (i.e., any Username other than the first)	N/A
Canonical name (e.g., cn=John Doe/o=Acme/c=US)	Distinguished name (DN)
Abbreviated name (e.g., John Doe/Acme/US)	Distinguished name (DN)
Short name/UserID (e.g., jdoe)	Userid (uid)
Last name	Surname (sn)
First name	Given name (givenName)

Note that although a wide range of user name formats makes it easier on the user, certain name formats could be ambiguous. The set of formats accepted by Domino can be restricted to just User name (cn), Canonical/Abbreviated name (DN) or Short name (uid) by changing the "Internet authentication" setting (in the Server document under the Security tab) to "Fewer name variations with higher security." In Domino R6, you can explicitly set the search filter used for the user name lookup for authentication if you use an LDAP directory via the Directory Assistance feature.

(Note: Apparently Domino performs slightly different searches on DIIOP requests vs. HTTP requests . For DIIOP session initiation, such as used when establishing a remote session via the Domino Java classes, only the User name variation is accepted.)

If WebSphere is authenticating, the name formats accepted are controlled by the "User filter" setting in the "Advanced LDAP Settings" page of the LDAP User Registry configuration. The default filter is

 (&(uid=%v)(objectclass=inetOrgPerson))

which searches for the user name as a uid attribute value.

Since Short name/ uid is common to both Domino and WebSphere authentication and is simple to specify, it is a good candidate for the SSO name format. However, keep in mind that the UID values must be unique among all LDAP directory entries. A useful choice for the UID value would be a person's fully qualified Internet e-mail name or address. Internet e-mail names are familiar to users, flexible in format, and, most importantly, unique to each user.

For SSL client certificate-based authentication, once the client itself has been authenticated via the certificate, the user name in the certificate is compared to the directory entry name for authorization. Though this sounds simple enough in theory, several complications arise when using client certificates in practice. One complication is that the format of the user name in the certificate is dictated by the Certificate Authority (CA) that creates the certificate. The X.509 certificate standard requires that certificate user names be unique under a single CA. The certificate user name usually includes attributes not part of the user DN in the directory, such as locality and country code attributes. As we will see later, WebSphere provides a way to handle mismatches between certificate and directory user name formats via a special LDAP search filter for the certificate name lookup.

Domino's handling of certificate-based authentication is more stringent. Users that need to be authenticated by a Domino Web server via client certificates must exist in a Domino directory and not an LDAP extension. The client certificates themselves must be imported into Person documents via a Notes client or via the Domino Certificate Authority function. The client certificate name must match the Username value in the Person document. For WebSphere, only the certificate user name must be found in the user directory, and there is no requirement that the certificate itself be part of the directory entry.