| Domino uses HTTP basic authentication whenever a Web user requests access to a Domino database whose ACL restricts access and client-side SSL authentication is not in effect. A Domino database ACL restricts access when the Default and Anonymous entries are set to "No Access." The name and password supplied by the user is verified against the Domino directory and any external directories configured via a Directory Assistance database. Domino can be configured to match various forms of the user name against the directory entry, including the common name, the last name, the short name, or the full distinguished name ("canonical name" in Notes terminology). The password is compared against the Internet password specified in a person document in the Domino directory or, by default, the userPassword attribute of the inetOrgPerson schema in an LDAP directory. You can specify the realm name Domino will return on the basic authentication challenge by creating a Web Realm document associated with the Server document. By specifying the realm name to be the same as that used by WebSphere, you can affect a sort of simple SSO since most browsers will return the same userid and password for URLs within the same realm. Of course, this simple SSO scheme does not extend to the case where Domino and WebSphere are on different servers. WebSphere can be told to use basic authentication for the Web components of any J2EE enterprise application. For an enterprise application configured to use basic authentication, WebSphere challenges the user for a name and password whenever an attempt is made to access a protected enterprise application Web resource. Both Domino and WebSphere can be configured to perform user authentication via SSL V3 client certificates. However, there are some limitations to using client certificates on the Domino side especially for SSO. We'll discuss more about these limitations later in this chapter. In addition to the user authentication functions, WebSphere provides for persistent or session-based authentication by means of a mechanism called Lightweight Third-Party Authentication (LTPA). It is this LTPA mechanism that was added to Domino and is used to provide SSO between Domino and WebSphere servers. Under LTPA, after a user is authenticated, the authenticating server generates a token, which is passed to the client as a cookie. On subsequent requests for protected resources within the same domain, the cookie is returned to the Domino or WebSphere server, and, if found to be valid, accepted as proof of the user's identity. Using LTPA, either Domino or WebSphere can perform the initial user authentication, and either can accept the generated LTPA token for authorization of subsequent requests. Let's take a closer look at the LTPA cookie and token. The cookie consists of standard fields defined by HTTP set to specific values for LTPA and the cookie value itself set to the LTPA token. The cookie fields are set as shown in Table 12-1. Table 12-1. LTPA Cookie Contents | Cookie Fields | LTPA Cookie Contents | | Domain and Path | Set to the Internet domain name of servers recognizing this cookie, stored in plain text (unencrytped) format. | | Cookie Expiration | Set to transient , meaning that the cookie is not stored on the browser system and is available only for as long as the browser is active. | | Cookie Value | Set to the LTPA token. |
The LTPA token consists of the contents listed in Table 12-2. Table 12-2. LTPA Token Contents | User Data | User name and attributes stored as name/value pairs separated by a "$." One of the attributes is the LDAP Realm , which consists of the host name and port of the user directory used for user validation. | | Expiration Date | The time and date the LTPA token will expire ”that is, will no longer be recognized as valid by a server system. | | Digital Signature | A digital signature of the User Data and the Expiration Date signed with the private key of the authenticating server (a private key generated specifically for LTPA). |
The entire LTPA token is encrypted (using triple-DES encryption) using a key shared among all the servers participating in LTPA. Other servers can verify the LTPA token signature by using the LTPA public key of the signing server. The shared DES key and server public keys are kept in a LTPA key ring, which can be exported from WebSphere and imported to Domino and other WebSphere servers. (Note that Domino is capable of exporting an LTPA key ring, but this export is in a format that WebSphere cannot understand, so for SSO between WebSphere and Domino, the LTPA key ring must be generated and exported from WebSphere to Domino.) The Role of the User Directory An important aspect of both Domino and WebSphere authentication mechanisms (either basic or certificate-based) is that they must validate user names against a user directory of some sort. For SSO, naturally, the user name directory must be shared. Directory sharing is indeed possible with Domino and WebSphere since both products support the widely used Internet specification for directory access called the Lightweight Directory Access Protocol (LDAP). A brief digression on LDAP and X.500 directory structure and naming may be helpful for our discussion of user directories. LDAP grew out of an effort to make the ITU/CCITT X.500 directory access protocols easier to implement on the Internet. It can be thought of as a simplified protocol for accessing X.500-based directory databases. The X.500 directory standard was intended to standardize and allow sharing of user (and other entity) information across organizations and countries . Its legacy is primarily the standards defining directory structure and naming. Briefly, with X.500, the directory information is organized as a tree with "entries" as nodes. Each entry in the directory tree consists of a set of attribute/value pairs and is assigned a unique name, referred to as a "distinguished name" (DN). A DN consists of a sequence of attribute value pairs. The pair sequence contains the DN of the parent entry and at least one pair for the entry itself. For example, an entry representing one of us might have a DN of: "cn=M.Laskey,ou=IBMGS, o=IBM,c=US," formed from the attributes common name (cn), organizational unit (ou), organization (o), and country (c). The set of attributes that may be included in an entry is defined by one or more "object classes." The set of attribute and object class definitions for a directory is specified by a "directory schema." LDAP itself is an Internet (IETF-RFC) standard that defines a simplified query and update protocol to an X.500 structured directory. Because of its popularity and wide usage, it has overshadowed its X.500 parent. To be precise, we should write "LDAP accessible directory" since LDAP is a network protocol intended to simplify query and update access to an X.500 directory. However, LDAP has come to be synonymous with not only the access protocol, but the X.500 directory content as well. So we will use the term "LDAP directory" from here on to mean both. Domino supports LDAP in two ways: 1) the Domino server supports access to its directory (the Domino public name and address book ”names.nsf) via LDAP, and 2) the Domino address book can be configured to query an LDAP directory via the Directory Assistance database feature. This means that either the Domino address book database itself can be used as the shared user directory or that an independent LDAP directory can be established and used by Domino. WebSphere refers to the user name directory as the "user registry" and supports LDAP access to the user registry for user authentication purposes. WebSphere makes the decision about what type of user directory to use easy: WAS requires an LDAP user registry type when the LTPA mechanism is configured. Therefore, an LDAP user registry is required for WAS/Domino SSO. The Domino and WebSphere support for LDAP allows several user directory configurations for SSO. There is no best configuration. Which is best for you may depend on your experience, whether you're already using Domino or another LDAP directory (such as the IBM Directory Server or OpenLDAP), or perhaps cost. Some of the possible configurations include the following: -
Defining all users to a Domino directory and connecting WebSphere to the Domino directory via LDAP. -
Defining all users to a stand-alone LDAP directory and connecting both Domino and WebSphere to it. -
Defining Internet users to a stand-alone LDAP directory and internal (Notes-only) users to a Domino directory and connecting Domino and WebSphere to the LDAP directory. | 