IBM/Lotus Domino and WebSphere Portal: Single Sign-on)

Summary
IBM WebSphere Portal brings great value to IT companies, enabling them to create powerful web applications that allow users to access in a centralized manner and provide personalized information. Companies can benefit from portals, such as simplifying infrastructure, accelerating development, and improving employee productivity.

Similarly, e-workplaces can change the contact information between employees and customers, other internal members, and suppliers. One of the foundations of a collaborative portal is its ability to bring geographically dispersed teams together to solve business problems by using collaborative applications.

In order to bring about this transformation, people often mistakenly think that these collaborative applications need to be transplanted between the same technical platform as the portal (such as J2EE, and abandon their integration (and potential portal deployment) due to complexity and spiraling costs ).

Contrary to this wrong idea, the key to maximizing value through this transformation lies in, it successfully integrates domino into the WebSphere Portal environment and more specifically implements the Single Sign-On (SSO) capabilities between the two platforms. This is the key focus of this White Paper. Common or single-point logon across WebSphere and Domino servers is provided, which is a major integration point between the two application environments, at the same time, it also enables companies to take advantage of the transaction advantages of Websphere servers and the Collaboration advantages of Domino servers. The web applications generated by this integration expand the performance of both environments at the same time. Although these web applications are actually running on different application servers, it provides a built-in mechanism or context that allows users to log on to the site only once, thus ensuring the seamless appearance of the application, it also provides powerful impetus for IBM's WebSphere Portal strategy for today's market, which uses WebSphere Portal as a separate access point to provide personalized and customizable data.

The remaining sections of this White Paper detail the core features of Single Sign-On between IBM WebSphere Portal and Lotus Domino to give you a basic understanding of this feature, it also provides solutions to the potential difficulties faced by the two environments in coordination and coexistence.

Introduction
This White Paper aims to discuss the use of Lotus Domino and Lotus collaborative products in the WebSphere Portal environment. This White Paper will discuss several scenarios that enable Lotus collaborative products to work in the WebSphere Portal framework, as well as the configuration of Domino Directory compliance (Domino Directory Service) in this environment. This White Paper focuses on using the original tools in WebSphere Portal and Domino to provide a single sign-on experience.

Target readers
This document is intended for the readers of Domino and WebSphere Portal administrators or IT architects who need to use the original SSO features of these products to integrate WebSphere Portal into the existing Domino environment. This document does not discuss how to use other products (such as Tivoli Access Manager) to implement SSO.

Tivoli Access Manager (TAM) solution for customers who want to integrate security between different types of Web applications (including products other than WebSphere Portal and Domino) in a centralized manner, or those customers who need flexible authentication options (labeling, certificates, etc.) and enhanced access control mechanisms (daily inspection, weekly one-day inspection, etc, and those customers who have chosen Tam for security and SSO architecture are the most suitable.

What is single sign-on?
Strictly speaking, Single Sign-On means allowing users to log on to an application. This application has a authenticated access channel to other applications. After logging on to this application, the user does not need to undergo any other authentication. In more practical terms, it includes a mechanism that maps the main logon to other applications for the login of the same user.

Our goal is to provide SSO with the ability to log on to the WebSphere Portal and allow access to the domino environment, Domino, sametime, QuickPlace, and other Domino-based tools using user creden. If there is no SSO relationship between the WebSphere Portal and the domino environment, each time the user accesses an application that containsProgramOr service information, you must log on to the domino environment. In addition, some WebSphere Portal APIs and services, such as online user awareness, do not provide logon tools. Even if these services do not provide unique logon tools, they still require SSO authentication to run.

WebSphere Portal provides the credential vault feature. Credential vault uses the basic authentication header to pass the user name and password to the backend application. In order for the Domino server to accept the creden。 passed in through this header, the server session authentication must be configured in single-server mode. In multi-server mode, the server will only accept certificates passed through the ltpa mechanism. Therefore, to use the credential vault for SSO with Domino applications, you must configure the Domino server session authentication to single-server mode.

To use the credential vault, you need to enter some credenvault. You only need to enter the credenvault once. Subsequently, these creden。 are stored in an encrypted database table. When a user accesses the Portlet, these creden。 are passed to the backend application. For details about how to configure the credential vault, see WebSphere Portal infocenter.

Most companies want to provide an automated way to use certificates currently from WebSphere Portal to authenticate backend applications.

How does it work?
Single Sign-On between WebSphere Portal and Lotus Domino is implemented through a mechanism called Lightweight third-party authentication (ltpa. The Websphere Application Server (including WebSphere Portal and any other applications running in the WebSphere environment) and Domino use ltpa. When the ltpa mechanism is used in an environment composed of multiple servers, it is enabled by using domain cookies. This encrypted session cookie is placed in the user's browser and contains some information, which can be encrypted by WebSphere or Domino application server, this information indicates that the user has passed the authentication in the Domain Name Service (DNS) domain covered by the cookie.

The ltpa cookie contains the following information:

• Cookie name: always set to ltpatoken.
• Domain: set to an internet domain, which is shared by all servers participating in single-point Logon (for example, mycompany.com ).
• Cookie Expiration: it is set to delete the cookie when the browser's life ends.
• Security: Set to on to force the use of Secure Sockets Layer (SSL ). There is an ltpa configuration with a set parameter so that it creates a cookie sent only through SSL.
• Cookie value: This is set to the ltpa tag and will be described later.

The ltpa tag is an encrypted string that contains the following information:

• User Data: generally set to user ID, but it can also be any user information used to uniquely identify a user.
• Expiration time: different from Cookie expiration, this field is used to impose a time limit, the time limit starts from the moment you log in, and is not affected by browser activity or inactivity. This time limit is a configurable ltpa setting. The default value is 30 minutes.
• Digital Signature: used to confirm the mark.

This document does not discuss the security of this method, but rather describes how to enable and use the provided mechanisms. For more information about the ltpa mechanism, see IBM Redbook: IBM WebSphere v4.0 advanced edition Security (http://www.redbooks.ibm.com ). For more comprehensive security solutions, IBM provides Tivoli Access Manager.

Scenario overview
This section of the document discusses the options used to establish SSO between WebSphere and Domino. It is divided into a large number of scenarios, which represent various environments that appear on the customer site. If you already have an environment, read the section that best matches your environment. If you are creating a new environment, read all these sections and select a scenario that provides the required functions.

These scenarios are divided into the following two types:

A directory serves both WebSphere Portal and Domino

This scenario represents some environments where a separate LDAP directory is used in the WebSphere Portal environment. If Domino exists in this environment, the Domino server provides the LDAP service. Otherwise, it is one of the supported LDAP servers or one of the LDAP servers supported by Domino. If Domino is only used to support QuickPlace and Sametime in WebSphere Portal (they are Domino-based applications), you can configure it to use a non-Domino LDAP directory. If Domino is used outside the WebSphere Portal environment, it is usually used as a Web application server rather than an email service. WebSphere Portal is configured to authenticate users according to this directory. You should note that WebSphere Portal (and WebSphere Application Server) can be configured to perform authentication only based on a separate LDAP directory.

For the entire enterprise, it is possible to use the Domino server as an LDAP server. The Domino server provides LDAP support, which can be used to authenticate from the WebSphere Portal and other applications. If Domino is used as the enterprise LDAP, this environment will be considered as a single directory environment.

Separating the Domino Directory and the WebSphere Portal directory

In these scenarios, there are usually Domino infrastructure in the environment, and there are separate directories for Domino and WebSphere Portal. Usually, the Domino Directory contains information about each Domino user, and the company LDAP directory contains a superset of this group. The company LDAP directory must contain user records for each user who wants to access the WebSphere Portal. When a given user is a domino user, some information must be coordinated between two records. This is usually done manually or with tools, such as using IBM directory Integrator (IDI ).

To make this method work, you must establish a single sign-on ltpa relationship between the WebSphere Portal environment and the domino environment. See information about the configuration server in portal infocenter and WebSphere Portal release notes.

Note that even if no ltpa relationship is established, some behavior similar to SSO from WebSphere Porta may still be seen. This is because there are two different ways to authenticate users entering the domino environment from the WebSphere Portal. To understand how these two methods work, it is important to understand the integration points from WebSphere Portal to Domino.

WebSphere Portal to Domino

The Portlet integrates the WebSphere Portal and backend applications. When you want to request information from an external application and display it on the WebSphere Portal page, the Portlet acts as a proxy (not strictly speaking, but the Portlet does execute some of the same functions ). The Notes Mail Portlet demonstrates this behavior. The WebSphere Portal requests data from the Domino server with the user name. WebSphere Portal uses the current user credential (which is collected from session information) to request information in the Domino server. The Portlet then formats the request and sends it to the Domino server. When the data is returned, it has been formatted and added to the WebSphere Portal page, and then sent to the user's browser for viewing.

When you log on to the WebSphere Portal, you need to use the LDAP attribute, which is usually a unique abbreviation of the user name, employee serial number, or some other unique identifier. After the WebSphere Portal receives a confirmation of the user name and password, or receives the existing ltpa tag from the LDAP server, it will collect other information containing the complete user identification name (DN. The information is then cached on WebSphere Porta until the user logs out of the server or the session ends. Once this information is aggregated on the Portlet, an HTTP, IIOP, or LDAP request is created and sent to the Domino server. When the Domino server receives the request, it obtains the user credential and uses the domino authentication and authorization tool to check whether the user has the right to obtain the information. If authentication and authorization are licensed, the information will be retrieved and returned to the WebSphere Portal in XML format. If you request information without authorization, the WebSphere Portal will receive the returned error message.

There is also a special case for using many Domino Portlet. When you are in the domino Portlet configuration mode, you can retrieve the list of valid databases through the diiop interface of the Domino server. The only difference between an IIOP connection and an HTTP connection is that the protocol used to communicate with the Domino server is different. The ltpa information sent to the Domino server is the same as the HTTP request.

To enable this level of SSO to work, the DN and the related password must match the Domino and WebSphere Portal. This is a secondary effect of providing SSO at this level for Domino server integration in WebSphere Portal. The user's WebSphere Portal username and password will be passed together.

Domino Browser

The second transaction involving SSO occurs between the user's browser and the Domino server. These transactions occur when you open a Lotus Notes document from the websphereportal interface or open any domino application in the iframe Portlet. If you check the entries in the Notes Mail Portlet or notes view Portlet, you will notice that the HTML link is directed to the Domino server and bypasses the WebSphere Portal.

Because WebSphere Portal is not included in the transaction, the user's identity is passed through the ltpa cookie, which is created when the user passes the WebSphere Portal authentication. The ltpa cookie contains the user's DN, Which is retrieved from the LDAP directory at login. The encrypted ltpa cookie information is transmitted to the Domino server together with the HTTP request.

To use SSO to process ltpa cookies created by websphere, a valid key must be generated on the Domino server ). WebSphere administrator's console has a tool in the security center that can export an ltpa key, which can then be imported into Domino, A public key is provided between two environments. Although the Domino server can consume the key keys created by websphere, Domino cannot export its own ltpa key keys.

The rest of this document describes how to configure WebSphere Portal and Domino to support these two types of SSO.

Single-user directory Environment
As discussed earlier, these two scenarios apply to two different configurations. One is to use Domino LDAP as their main directory environment, and the other is to use all applications, this includes the environment in which Domino points to another supported LDAP directory.

Use the Domino Directory

The Domino server provides an LDAP service. WebSphere Portal can be configured to use the Domino LDAP service for authentication. This is the simplest environment, because user creden。 and passwords are generated from the same source (through LDAP or the original Domino ).

The only required configuration step is to export the ltpa key from the WebSphere server and import it to the Domino server. The same key and secret must be shared among all WebSphere servers, which will be part of the SSO domain. Basic security settings, such as timeout, LDAP server and DNS domain must be consistent across all WebSphere servers.

The Domino server must be configured as multi-server SSO for multi-server SSO after the key is imported. For more information about how to configure the server, see the current WebSphere Portal infocenter and readme file.

The sametime 3.x and QuickPlace 3.x servers can be configured to use the original Domino Directory or Domino DAP service.

Use a non-Domino Directory

WebSphere Portal supports IBM Directory Server, Microsoft's Active Directory, Iplanet, and Novell's eDirectory. Domino can be configured to support these directories under specific conditions.

In order for emails to be routed within the domino environment, there must be directory records containing mail information (such as mail files and email servers for each user. This document can be a person document in Domino Directory, a mail-in database document, or an extended schema in the LDAP directory.

Domino and Directory Maintenance ance

The Domino server has a mechanism for linking to an external LDAP directory named Directory Maintenance ance (DA. This mechanism allows the Domino server to search for one or more LDAP directories after searching the Domino Directory for user identity authentication. Da creates a directory compliance database from the provided template, enters the database name in the server document, and adds a document to the database to activate the database.

The group and user management can be completed from the LDAP directory. The only restriction is mail routing. The User Name Reference in the ACL. The group members and other context environments must be the modified version of the user's ldap dn. The modification is completed in the domino environment. In the domino environment, LDAP is replaced by commas. So

CN = Elizabeth somebody, ou = users, O = yourco

Change

CN = Elizabeth somebody/ou = users/o = yourco.com

Even if you have configured directory authentication ance and want to provide single-point logon, you still need to configure the ltpa relationship between WebSphere Portal and Domino. Both the QuickPlace and Sametime environments should be configured for Identity Authentication Based on the same directory as WebSphere Portal. For more information, see the documentation provided with these products. You can use QuickPlace 3.0 to directly access LDAP without the need for directory compliance. Sametime 3.0 depends on directory to help Federation get information from LDAP. Sametime should be configured to use the original Domino Directory for most flexible online user awareness.

Using directory Federation in some environments works. The same users in these environments are not listed in the LDAP directory or in the Domino Directory. If you only execute Domino to support QuickPlace and Sametime, you can use this type of configuration. If the domino infrastructure already exists in a more complex environment and more domino functions need to be used, it is necessary to configure multiple directories.

Separate multi-directory Environments
Although the ultimate goal of most organizations is to obtain a separate directory, it is common to have at least two directories, or even more directories. For non-Domino applications, you should use the Domino Directory and the general LDAP directory for non-Domino applications. There is usually an additional LDAP directory dedicated to some specific applications.

WebSphere Portal relies on the underlying WebSphere Application Server for authentication. The WebSphere Application Server is restricted to identity authentication based on a separate user repository. This means that all users using WebSphere Portal must be located in a separate instance in the main directory (usually LDAP.

Domino's directory requirements are completely different. To obtain the complete functions of the Domino server, including mail routing, an entry is required in the Domino Directory for each user. Ideally, organizations with existing Domino environments will use the Domino Directory for identity authentication in the WebSphere Portal. However, in reality, restrictions in the implementation of Domino LDAP, multi-mail systems, application-specific LDAP requirements, and many other factors prevent this situation from making this approach unfeasible.

Multiple Identities

Separating the directories used for WebSphere Portal and Domino and providing SSO between them directly results in the emergence of a situation in reality, we call this situation multiple identities problem (Multi-identity problem ). It is important to understand how to configure different parts to solve related problems.

We will discuss the issue of multiple identities by defining an example environment, which is similar to what can be seen in a common environment. Our example company name is yourco. Yourco has a master LDAP directory, which has users distributed in branch offices in each city under the ou for users. Therefore, for our example employee Elizabeth somebody, the following information is contained in her LDAP record. We reference this LDAP record as her LDAP identity.

Field	Value
DN	Elizabeth somebody, ou = Boston, ou = users, Dc = yourco, Dc = com
UID	Esomebody

In the existing Domino environment, Elizabeth's person document contains the following values, which we will reference as her Domino identity.

Field	Value
First name	Elizabeth
Last name	Somebody
User Name	Elizabeth somebody/Boston/yourco Elizabeth somebody
Short Name	Esomebody

Elizabeth uses her ldap uid (esomebody) to log on to the WebSphere Portal. As part of the identity authentication process, WebSphere Application Server finds her complete DN from the LDAP directory and uses it to create ltpa cookies. When she is accessing the WebSphere Porta page as an authenticated user, Lotus collaborative components of WebSphere Portal collects her user information (public name, LDAP uid, and DN) from WebSphere Portal ). Then, it tries to initialize the sametime links connection with the Sametime server. When this link is established, the public name is provided to sametime to initialize Elizabeth and provide online awareness for Elizabeth. When Elizabeth accesses a WebSphere Portal page containing the notes Portlet, her dn is passed to the Domino server over HTTP. Then the Domino server searches the Domino Directory to find the DN, but the DN cannot be found in the Domino Directory (ltpa cookie is not used here ).

Obviously, the solution is to enable directory authentication on Domino to add the LDAP server to the authentication path. When the task is completed, the search for the DN will now be transferred to the LDAP directory, where you will find a matching item and the user will also pass authentication. The problem is that Elizabeth is authenticated by the following identities:

CN = Elizabeth somebody, ou = Boston, ou = users, Dc = yourco, Dc = com

Domino does not know that this is the same user as the user mentioned below.

Elizabeth somebody/Boston/yourco

Everything Elizabeth does in the domino environment will be done in her LDAP identity. For example, when Elizabeth sends an email, the from field will contain her ldap dn. She will be able to find the address and send an email, but if the recipient replies to the email, they will receive a name not in the directory error (name not found in directory error ), because there is no Domino personal document with DN.

When Elizabeth creates a document in the domino database, the Creator metadata will contain her ldap dn. If the view is classified by the authors field, the documents created through WebSphere Portal will be in different positions than the documents created through the Notes client, it is also different from the documents created when you access Domino application directly from a Web browser.

In some databases, if Elizabeth's Domino identity is listed in the ACL, both explicitly listing and using group members, she will not be able to access these databases. This rule is also applicable to those documents with restrictions, which can be applied through the reader field or the author field.

With these restrictions, we can no longer use da as a solution to this problem. What is really needed is a method used to map LDAP identities to Domino identities. Fortunately, the Domino R5 server provides this feature.

The User Name field in the personal document is a multi-value field. as long as necessary, it can contain many variants of the user name. As the best practice, each entry in directory should be unique. When a match is found based on an entry in the field, Domino maps the identity to the first entry in the field for authentication purposes. This is usually the hierarchical version of the user name. To use this feature and solve problems previously discussed in Domino and directory compliance, we need to change Da, then add the user ldap dn (replace comma with/) after the second line of the User Name field ).

Now, when the Domino server receives the complete DN, it searches for the Domino Directory. The first search will still fail. If da is enabled on the server, DA will now search for the LDAP directory, and you will face the same problems you encountered earlier .; Otherwise, it checks all entries in the User Name field and finds a match for the full ldap dn (replace comma. Then the user LDAP dn is associated with the first entry, and the user authenticates as Domino. All their actions in the original Domino environment must be implemented through their Domino identity, and those actions in the WebSphere Portal environment must be implemented through the LDAP identity.

The same solution works when ltpa cookies are used. Because the ltpa cookie is created through the user's ldap dn, the Domino server finds the name in the User Name field and associates the name with his or her Domino identity.

Configure the domino Environment

The first thing to do is to configure the domino environment to establish an ltpa relationship between the WebSphere Portal Server and the Domino server. Directory Federation is disabled by default. However, if you use the DA cascade Domino address book, you can enable it. Do not include the corporate LDAP directory in the directory Federation path.

In each user's person document, at least one entry must be added to the User Name field. The first line of the field should already contain the complete level of Domino user name. The second entry should be the user's public name (CN), which appears in the format of firstname and lastname. When a user is registered, these entries are created by Domino and should be kept as they are. Other entries, such as public names, premarital surnames, and nicknames, may already exist and are ready. After this is done, we should add the ldap dn of the user in the domino format (use/to replace the comma ).

In the above example, the user's abbreviation name in LDAP matches the abbreviation name in the Domino Directory. Otherwise, the LDAP uid must also appear in the User Name field of the person document. This applies to other LDAP attributes, such as the Public name (CN. If the LDAP-recorded CN is different from the second line of the User Name field, the CN must be included in the user name to allow online sensing.

This example illustrates the different values required for the domino User Name field:

LDAP entry	Old Domino entry	New Domino entry
CN = elizabethsomebody, Ou = Boston, O = yourcouid = esomebody	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodybeth somebodyshortname = esomebody	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodybeth somebodycn = elizabethsomebody/ou = Boston/o = yourcoshort name = esomebody
CN = elizabethsomebody, Ou = Boston, O = yourcouid = y32483	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodybeth somebodyshortname = esomebody	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodybeth somebodycn = elizabethsomebody/ou = Boston/o = yourcoy32483short name = esomebody
CN = bethsomebody, Ou = Boston, O = yourcouid = esomebody	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodyshortname = esomebody	User name = Elizabeth somebody/Boston/yourcoelizabeth somebodybeth somebodycn = bethsomebody/ou = Boston/o = yourcoshort name = esomebody

Because WebSphere Portal may pass user names and passwords for some user authentication, you also need to synchronize the internet password between the Domino Directory and the LDAP directory. This is critical for using WebSphere Portal for complete Domino integration. Remember, there are still transactions between the Domino server and the WebSphere Portal that use creden。 used to log on to the WebSphere Portal.

These requirements will require constant maintenance by ongoing. This can be done manually or using tools, such as IBM directory integrator.

Sametime Configuration

The Sametime server should be configured to authenticate based on the original Domino Directory to allow online awareness. We recommend that you use the LDAP directory in version 3.0 sametime document. However, you can configure sametime in a multi-directory environment to use the native Domino Directory, which provides more flexible online awareness.

The specific example is the use of the notesview Portlet. If you enable online awareness for a column containing the user's public name, any directory (LDAP or native Domino) can be used. If the column contains the full name of the user, if sametime uses the LDAP directory, sametime cannot be determined online.

QuickPlace performs LDAP calls on the Directory Server, while sametime is different. sametime uses directory authentication ance for LDAP authentication. Because directory consistency is required for sametime running, da must be configured on Sametime. However, this is the only server to be configured. Although sametime awareness is valid, When you authenticate the domino application running on the Sametime server, you still encounter issues that have been discussed previously.

QuickPlace Configuration

When quickplace2.08 is used, you should Configure the server to use Domino as a directory. When you configure the underlying server for SSO, you must use a special version of The domcfg. nsf file. This version can be downloaded from www.lotus.com/support. This file contains an updated default domain login document, which executes some additional processing to maintain the ltpa cookie. If you use the default domcfg. nsf provided with Domino, The ltpa cookie will be overwritten when you access QuickPlace, and you will need to log on again when you return to WebSphere Portal.

Quickplace3.0 should be configured to access the same LDAP directory as the webspher portal. If you want to access an existing QuickPlace environment, this environment may be migrated from earlier versions, which may become a problem. You may need to use the changemember command to update the usernames in quickplaces to their LDAP Version. This allows users to maintain their QuickPlace functions in this environment.

If you need to use either the native Domino directory or the Domino Directory through LDAP, you need a patch that supports proper name ing.

Conclusion
Using the core features of Single Sign-On Between the WebSphere Portal environment and the domino environment can greatly improve user experience and productivity. With the information provided in this article, you have not only mastered how to best implement Single Sign-on, but also better understood the underlying details behind this core function. In addition, some methods described in this document will allow you to configure the WebSphere Portal environment and Domino environment to take advantage of their respective advantages. In a more complex environment, Tivoli Access Manager must be used.