Abstract IBM WebSphere Portal has brought tremendous value for IT, enabling them to create powerful web applications, which allow users to centrally access and provide personalized information. Companies can benefit from the portal, such as simplifying infrastructure, speeding up development processes, and improving employee work efficiency.
Similarly, e-Workplaces can transform the contact information between employees and customers, other internal members, and suppliers. One of the foundations of collaborative portal is that it has the ability to solve business problems by using collaborative applications to get geographically dispersed teams.
In order to bring this transformation, people often mistakenly believe that these collaborative applications need to be transplanted between the same technical platform (such as J2EE) as the portal, and abandon their integration (and potential) due to complexity and spiral rise. Portal deployment).
In contrast to this error, the key to obtain the maximum value through this transformation is to successfully integrate Domino into the WebSphere Portal environment and more specifically to achieve single sign-on between two platforms (Single Sign-ON, SSO )Ability. This is the key ability to focus on this white paper. Provides a general login or single sign-on login across WebSphere and Domino servers, which is a major integration point between the two application environments, but also enables the company to combine the use of WebSphere servers in business and Domino servers in collaboration. Advantage. This integrated Web application has expanded the performance of these two environments. Although these web applications actually run on different application servers, it provides the user to log in to the site's built-in mechanism or context environment, thereby maintaining seamlessness of applying appearance, and gives IBM for today's market The launch of the WebSphere Portal strategy provides powerful power, which is to provide WebSphere Portal as a separate access point to provide personalized and customizable data.
The remaining parts of this white paper detail the core functions of single sign-on between IBM WebSphere Portal and Lotus Domino, with the purpose of making you a basic understanding of this feature, and the potential for two environmental coordination Difficulties provide a solution.
Introduction The purpose of this white paper is to discuss issues related to the use of Lotus Domino and Lotus Collaborative products in the WebSphere Portal environment. This white paper will discuss several scenarios for working in the WebSphere Portal framework in the WEBSPHERE Portal framework, and the configuration of the Domino Directory Assistance (Domino Directory Service) in this environment. The focus of this white paper is to provide a single sign-on experience in using the original tools in WebSphere Portal and Domino.
Readers-oriented readers are Domino and WebSphere Portal administrators or IT architects, they need to use these products to integrate WebSphere Portal to existing Domino environments. This document does not discuss the issue of SSO using other products (such as Tivoli Access Manager).
Tivoli Access Manager (TAM) Solutions For customers who want to integrate security between different types of web applications, including WebSphere Portal and Domino, or those who need flexible certification options (tags, Certificates, etc.) and enhanced access control mechanisms (once a day check, weekly check, etc.), and those customers who choose TAM for security and SSO architectures are the most suitable. What is a single sign-on? Strictly said that single-point login refers to allowing users to log in to an application, this app with access to other applications, after logging in to this application, users don't have to encounter any other Certification. In terms of more practical words, it includes mechanisms that can map this primary login to other applications for the same user's login.
Our goal is that SSO provides the ability to log in to WebSphere Portal and allows you to use those user credentials to access the Domino environment, Domino, Sametime, QuickPlace, and other Domino-based tools. If there is no SSO relationship between the WebSphere Portal and the Domino environment, you need to log in to the Domino environment each time you accesses a portlet that contains information from Domino-based applications or services. In addition, some WebSphere Portal APIs and services, such as people in line, and do not provide login tools. Even if these services do not provide a unique login tool, in order to run them, they still need to authenticate via SSO.
WebSphere Portal provides the Credential Vault feature. Credential Vault passes the username and password to the backend application via the Basic Authentication Header. In order for the Domino server to accept the credential passed through this header, the server session verification must be configured as a Single-Server mode. In Multi-Server mode, the server will only accept credentials passed through the LTPA mechanism. Therefore, in order to use the Domino application with Credential Vault for SSO, you must configure Domino server session to be configured as Single-Server mode.
To use Credential Vault, users need to enter some credentials, enter once. Subsequently, these vouchers are stored in a encrypted database table, and these credentials are passed to the backend application whenever the user accesses the portlet. To learn about the details of configuring Credential Vault, see WebSphere Portal Infocenter.
Most companies want to provide an automated approach to use the current from WebSphere Portal to authenticate the backend application.
How does it work? Single sign in WebSphere Portal and Lotus Domino is implemented by a mechanism called Lightweight Third Party Authentication (LTPA). WebSphere Application Server (also included WebSphere Portal and other applications in WebSphere environments) and Domino use LTPA. When the LTPA mechanism is used in an environment consisting of multiple servers, it is enabled by using Domain cookies. This encrypted session cookie is placed in the user browser and contains some information, the WebSphere or the Domino Application server can encrypt this, and use this information to illustrate the DNS covered by the cookie (Domain Naming Service) , The authentication in the domain service) domain. LTPA cookie contains the following information:
Cookie Name: Always set to LTPATOKEN. Domain: Set to the Internet domain, which is shared by all servers participating in single-point login (for example: mycompany.com). Cookie expires: Set to remove the cookie when the life of the browser is terminated. Safety: Set to open state to force the security socket layer (SSL). There is a LTPA configuration with a setting parameter that creates a cookie sent only by SSL. Cookie value: This is set to LTPA tags, which will be described next.
The LTPA tag is an encrypted string that contains the following information:
User data: Generally set to the user ID, but can also be any user information for unique identity users. Expiration Time: Unlike cookies, this field is used to force a time limit, and time limit is counted from the moment of login, it is not affected by browser activities or inactivity. This time limit is a configurable LTPA setting, which is 30 minutes by default. Digital signature: Used to confirm the tag.
This document does not intend to discuss the security of this method, but to discuss how to enable and use the mechanism provided. To learn more about the LTPA mechanism, readers should refer to IBM Redbook: IBM WebSphere V4.0 Advanced Edition Security (http://www.redbooks.ibm.com). To get a more complete security solution, IBM provides Tivoli Access Manager.
This part of the scene overview discusss the options for establishing the SSO between WebSphere and Domino. It is broken down into a large number of scenes represent a variety of environments that appear in the customer site. If you already have an environment, you should read the most matching parts with your environment. If you are creating a new environment, you should read all these sections and choose the scenario that provides your desired feature.
These scenes are divided into two categories:
A directory for WebSphere Portal and Domino services
This scenario represents some environments, in which a separate LDAP directory is used in the WebSphere Portal environment. If Domino exists in this environment, then the Domino server provides an LDAP service, otherwise it is 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), then it can be configured 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 instead of email services. WebSphere Portal is configured to authenticate users based on this directory. You should notice that WebSphere Portal (and WebSphere Application Server) can be configured to authenticate only according to a separate LDAP directory. For the entire company, it is possible to use the Domino server as a LDAP server. The Domino server provides support for LDAP, which can be used to authenticate from WebSphere Portal and other applications. If Domino will be used as a business LDAP, then the environment will be viewed as a single directory environment.
Separate Domino Directory and WebSphere Portal Directory
In these scenarios, there is a Domino infrastructure in the usual environment, and there are separated directories for Domino and WebSphere Portal. Normally, the Domino directory contains information about each Domino user, and the company's LDAP directory contains a supercoming of the group. The company's LDAP directory must contain user records for users to access WebSphere Portal. In the case where a given user is also a Domino user, some information must be coordinated between two records. This is usually manually completed or done with tools, such as IBM Directory Integrator (IDI).
To make this method, you must establish a single sign-on LTPA relationship between the WebSphere Portal environment and the Domino environment. See the information about configuring the server in Portal Infocenter and WebSphere Portal Release Notes.
Note that even if the LTPA relationship is not established, it is still possible to see some behavior of SSO from WebSphere Porta. This is because there are two different ways to authenticate users from WebSphere Portal into the Domino environment. To understand how these two methods work, it is important to understand the integration point from WebSphere Portal to Domino.
WebSphere Portal to Domino
Portlets integrate WebSphere Portal and backend applications, when the user wants to request information from an external application and display it in the WebSphere Portal page, Portlet acts as a role of a certain agent (this is not a strict sense statement) However, the portlet does perform some of the same features). The Notes Mail Portlet demonstrates this behavior. WebSphere Portal requests data with the user name to the Domino server. WebSphere Portal uses the current user credentials (it is collected from the session information) requests the information in the Domino server. Then, the portlet formats the request and sends the request to the Domino server. When the data returns, it has been formatted and added to the WebSphere Portal page, and then sends to the user browser for viewing. When logging in to WebSphere Portal, you will need to use the LDAP property, which is usually the only user name abbreviation, the employee serial number, or some other unique identifiers. WebSphere Portal receives confirmation of the username and password of the user, or after receiving an existing LTPA tag from the LDAP server, it collects information that contains the full user ID (DN). This information is then cached on WebSphere Porta until the user is logged out from the server or the session is terminated. Once this information is collected on the portlet, this information creates an HTTP, IIOP, or LDAP request and send it to the Domino server. When the Domino server receives the request, it takes the user credentials and uses the Domino authentication and authorization tool to see if the user has the right to get this information. If the authentication and authorization are licensed, this information will be retrieved and transmitted back to WebSphere Portal in XML format. If the user does not have the authorization to request information, then WebSphere Portal will receive the returned error message.
There is also a special situation for many Domino Portlets. When in the configuration mode of the Domino Portlet, a list of valid databases can be retrieved through the DOMino server's DIIOP interface. The only difference between the IIOP connection and HTTP connections is different from the agreement with the Domino server. The LTPA information sent to the Domino server is the same as the HTTP request.
In order for this level of SSO to work, DN and related passwords must be matched between Domino and WebSphere Portal. This is the sub-effects of the SSO to which the Domino server is integrated in WebSphere Portal. The user's WebSphere Portal username and password will be delivered together.
Browser for Domino
The second set of transactions involved in SSO appears between the user browser and the Domino server. These transactions happen when the user opens a Lotus Notes document from the WebSphereportal interface or opens any Domino application in the IFRAME portlet. If you look at the entry in the Notes Mail Portlet or the entry in the Notes View portlet, you will notice the HTML link to be directed to the Domino server and bypass WebSphere Portal.
Since WebSphere Portal is not included in the transaction, the user's identity is passed through LTPA cookie, which is created when the user is created at the user's authentication through WebSphere Portal. The LTPA cookie contains the user's DN, which is retrieved from the LDAP directory when logging in. The encrypted LTPA cookie information is passed along with the HTTP request to the Domino server. To handle LTPA cookies created by WebSphere with SSO, you must generate a valid key key (key) on the Domino server. WebSphere Administrator's Console has a tool in Security Center, which can export an LTPA key key, which can then be imported into Domino, providing a common key key between the two environments. Although the Domino server can consume key keys created by WebSphere, Domino cannot export its own LTPA key key.
The remainder of this document relates to how to configure WebSphere Portal and Domino to support these two types of SSO.
The single user directory environment has been discussed. These two scenarios are suitable for two different configurations; one is to use Domino LDAP as their home directory, the other is to point all applications, including Domino points to another. The environment of the LDAP directory.
Use the Domino directory
Domino servers provide an LDAP service. WebSphere Portal can be configured to authenticate using Domino LDAP services. This is the easiest environment because the user credentials and passwords are generated from the same source (via LDAP or original Domino).
The only required configuration step is to export the LTPA key key from the WebSphere server and import it into the process of the Domino server. The same key key must be shared between all WebSphere servers, which will be part of the SSO domain. Basic security settings, such as timeout, LDAP servers and DNS domains must be consistent in all WebSphere servers.
The Domino server must be configured to be multi-Server SSO for multiple server SSOs after the key key is imported. To get more information about how to configure the server, refer to the current WebSphere Portal Infocenter and the 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 non-Domino directory
WebSphere Portal supports IBM's Directory Server, Microsoft Active Directory, IPlanet, and Novell's eDirectory. Domino can be configured to support these directories under specific conditions.
In order to route the email within the Domino environment, there must be a directory record that includes mail information (such as mail files and mail servers for each user). This document can be either in the Domino Directory, or a Mail-IN Database document, or extended Schema in the LDAP directory.
Domino and Directory Assistance
The Domino server has a mechanism for linking to an external LDAP directory called Directory Assistance (DA). This mechanism allows the Domino server to search for one or more LDAP directories after searching the Domino directory as the user authentication. DA Enter the database name in the server document from the supplied template, and then adds a document in the database to be activated. Then, groups and user management can be completed from the LDAP directory, the only limit is the mail route. In the ACL reference, group members, and other context environments need to be a modified version of the user's LDAP DN. Modifications are done in the Domino environment. In the Domino environment, the comma used by LDAP is replaced with / character. and so
CN = Elizabeth SomeBody, Ou = Uses, O = Yourco
Become
CN = Elizabeth SomeBody / ou = users / o = Yourco.com
Even if Directory Assistance is configured, you want to provide a single sign-on feature, you still need to configure the LTPA relationship between WebSphere Portal and Domino. The QuickPlace environment and Sametime environments should be configured to authenticate according to the same directory as WebSphere Portal. For more information, check the documentation provided with these products. You can directly access LDAP through QuickPlace 3.0 without Directory Assistance. Sametime 3.0 depends on Directory Help Assistance gets information from LDAP. For the most flexible implementation of people online sensation, Sametime should be configured to use the original Domino Directory.
Using Directory Assistance in some environments works, the same user in these environments is not listed in the LDAP directory, nor is it in the Domino directory. This type of configuration can be used if Domino is implemented only for QuickPlace and Sametime. In a more complex environment, if there is already a Domino infrastructure, you need to use more Domino functions, it is necessary to configure multiple directories.
Separation Multi-Catalog Environments Although most organizations' ultimate goals are a separate directory, more typically, there are fewer directorys, and there are more directorys are also common. For non-Domino applications, Domino Directory should be used and a universal LDAP directory for non-Domino applications. There is usually an additional LDAP directory specifically for certain specific applications.
WebSphere Portal is certified by the underlying WebSphere Application server. The WebSphere Application server is limited to authenticate according to a separate user library (user repository). This means that all users who are using WebSphere Portal must be in a separate instance of the primary directory (usually LDAP).
Domino's directory demand is completely different. In order to obtain the full functionality of the Domino server, including mail routing, you need to have an entry in the Domino directory for each user. In the ideal case, organizations with existing Domino environments will use the Domino directory to authenticate in WebSphere Portal. However, in reality, the limitations in Domino LDAP implementations, multi-mail systems, applicable LDAP demands and many other factors avoid this situation makes this way.
Multiple identity
Separation of directory for WebSphere Portal and Domino, and providing SSOs between the two, such a realistic demand in reality, directly leading to the generation of the situation, we call this situation is Multiple Identities Problem (more identity problem). It is important to understand how to configure different parts to solve the relevant problems, and understand the essence of this problem is important. We will discuss multi-identity issues by defining an example environment, which is similar to what the usual environment can see. Our sample company name is Yourco. Yourco has a primary LDAP directory, with users who are distributed in branches of each city under OUs of the user. So for our sample employee Elizabeth SomeBody, there is the following information in her LDAP record, and we reference such LDAP record as her LDAP identity.
Field value Dnelizabeth Somebody, Ou = Boston, Ou = Uses, DC = Yourco, DC = ComuideSomebody
In an existing Domino environment, Elizabeth's Person document contains the following values, we will reference these values as her Domino identity.
Field Value First Nameelizabethlast NamesomeBodyUser Nameelizabeth Somebody / Boston / Yourco Elizabeth SomebodyShort Nameesomebody
Elizabeth is logged in with her LDAP UID (ie EsomeBody) to WebSphere Portal. As part of an identity authentication process, WebSphere Application Server finds her full DN from the LDAP directory and establishes LTPA Cookies with it. When she accessed the WebSphere Porta page as a certified user, WEBSPHEREPORTAL LOTUS COLLABORATIVE Components (LCC) collects her user information (common name, LDAP UID, and DN) from WebSphere Portal. The LCC is then initialized to initialize the Sametime Links connection with the Sametime server. During this link, the utility is supplied to Sametime to initialize Elizabeth, and provide people in Elizabeth. When Elizabeth accesses a WebSphere Portal page containing Notes Portlet, her DN passed to the Domino server via HTTP. The Domino server is then search for Domino Directory to find DN, but in Domino Directory is not found in DN (there is no LTPA cookie here).
Surface obvious solution is to enable Directory Assistance on Domino to join the LDAP server into the authentication path. When the task is completed, the search for DN will now be transferred to the LDAP directory, in which you will find a matching item and the user will pass authentication. The problem is that Elizabeth is certified as follows:
CN = Elizabeth SomeBody, Ou = Boston, Ou = Uses, DC = Yourco, DC = COM
And Domino doesn't know that this is the same as the following users.
Elizabeth Somebody / Boston / Yourco
Elizabeth will do everything in the Domino environment will be carried out as her LDAP. 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 mail, but if the recipient replies to the message, they will receive a name not found in the directory (Name Not Found In Directory Error) because there is no DNo 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 according to the Authors field, then the document created by WebSphere Portal will be set in different locations compared to documents created by the Notes client, which is different from those created from a web browser to Domino Application Directly. Documentation.
If you are listed in the ACL in some databases, you will not access these databases in ACLs in the ACL, whether it is explicitly listed or through group members. This rule is equally applicable to those limited documents, which can be applied through the Reader field or applying it through the Author field.
Because of these restrictions, we can no longer use DA as a solution to this problem. Really needed is a way to map LDAP identity to Domino identity. Fortunately, Domino R5 servers provide this feature.
The User Name field of the personal document is a multi-value field, as long as it is necessary, it can contain many varieties of the user name. As the best best practice, each entry in Directory should be unique. When a match is found in accordance with an entry in this field, Domino maps the identity to the first entry of the field to the authentication purpose. This is usually a layered version of the username. To take advantage of this function and resolve issues previously discussed in Domino and Directory Assistance section, we need to change DA, then add users LDAP DN (with / replace comma) after the second line of the USER Name field.
Now, when the Domino server receives a complete DN, it searches for 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 problem you have previously encountered. On the contrary, it checks all entries for the USER Name field and finds a match that complete LDAP DN (with / replaced comma). The user LDAP DN is then associated with the first entry, and the user is authenticated as Domino. They are now implemented through all their behaviors in the original Domino environment, while those in the WebSphere Portal environment should be implemented by LDAP.
When using LTPA cookies, the same solution will work. Because LTPA cookies are created by the user's LDAP DN, the Domino server will find that name in the user name field and associate this name or her Domino.
Configuring a Domino environment
The first thing to do is to configure the Domino environment in order to establish an LTPA relationship between the WebSphere Portal server and the Domino server. Directory Assistance is off default. But if you use the DA Class Domino Address Book, you can enable it. Don't include a corporate ldap directory in the Directory Assistance search path. In each user's Person document, at least you need to add an entry in the User Name field. The first line of the field should already contain a complete hierarchy Domino username. The second entry should be the user's common name (CN), which appears in firstname, lastname format. When a user is registered, these entries are established by Domino and should be maintained. Other entries, such as other forms of common names, marriage last name and nickname may already exist and ready. After doing this, we should join the LDAP DN of users in Domino format (with / replace comma).
In the above example, the user's abbreviation name is matched with the abbreviated name in the Domino directory. If this is not this, the LDAP UID must also appear in the User Name field of the Person document. This is equally applicable to other LDAP properties, such as the common name (CN). If the CN recorded by the LDAP is different from the second line of the USER NAME field, the CN must be included in the username to allow the person to know online.
This example illustrates the different values required to Domino User Name field:
LDAP entry Old Domino entries New Domino entry cn = ElizabethSomebody, ou = Boston, o = YourCouid = esomebodyUser Name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyBeth SomebodyShortname = esomebodyUser Name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyBeth Somebodycn = ElizabethSomebody / ou = Boston / o = YourCoShort Name = esomebodycn = ElizabethSomebody, ou = Boston, o = YourCouid = y32483User Name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyBeth SomebodyShortname = eSomebodyUser Name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyBeth Somebodycn = ElizabethSomebody / ou = Boston / o = YourCoy32483Short name = esomebodycn = BethSomebody, ou = Boston, o = YourCouid = esomebodyUser name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyShortname = esomebodyUser name = Elizabeth Somebody / Boston / YourCoElizabeth SomebodyBeth Somebodycn = BethSomebody / ou = Boston / o = YourCoShort name = esomebody since WebSphere Portal may pass usernames and passwords for certain user authentication, so you also need to synchronize the Domino directory and the Internet password between the LDAP directory. This is critical to the complete Domino integration with WebSphere Portal. Remember, there is still a transaction between Domino Server and WebSphere Portal, which uses credentials used to log in to WebSphere Portal.
These requirements will need ONGOING to keep maintenance. This can be done manually or in use of tools, such as IBM Directory Integrator.
Sametime configuration
The Sametime server should be configured to be authenticated according to the original Domino Directory to allow people to know online. The 3.0 version of the Sametime document is recommended to use the LDAP directory. However, configure Sametime in a multi-directory environment to use the Native Domino directory, which provides more flexible personality online sensation.
The specific example is the use of Notesview Portlets. If the person is opened online for a list of a common name containing the user, then any directory (LDAP or NATIVE DOMINO) can be used. If the column contains the full specification name of the user, if Sametime is using the LDAP directory, Sametime will not be able to determine the online state.
QuickPlace performs LDAP calls for the directory server, while Sametime is different, and Sametime uses Directory Assistance when authentication is performed in accordance with LDAP. Because Directory Assistance is required for Sametime, you must configure DA on Sametime. But this is the only server that needs to be configured. Although Sametime Awareness will be effective, you will still touch the issues previously discussed when you authenticate the Domino application running on the Sametime server. QuickPlace configuration
When using QuickPlace 2.08, you should configure the server to use Domino as a directory. When you configure the underlying server for the SSO, you must use a special version of the DOMCFG.NSF file. This version can be downloaded on www.lotus.com/support. This file contains an updated default domain login document that performs some additional processing to maintain LTPA cookies. 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 in again when you return to WebSphere Portal.
QuickPlace 3.0 should be configured to access the same LDAP directory as WebSpher Portal. If you want to access an existing QuickPlace environment, the environment is transplanted by earlier versions, which may become a problem. You may need to use the CHANGEMEMBER command to update the username in QuickPlaces to their LDAP version. This will allow users to maintain their QuickPlace feature in this environment.
If you have such a requirement, you must use the native Domino directory, or use the Domino Directory directory through LDAP, then you need to have a patch that supports the appropriate name mapping.
Conclusion The core function of single sign-on between the WebSphere Portal environment and the Domino environment can greatly improve the user experience and improve their work efficiency. With information provided herein, you can't just understand how to achieve single sign-on, but also better understand the underlying details behind this core function. In addition, some methods of this document will allow you to configure the WebSphere Portal environment and the Domino environment to take advantage of their respective advantages. In a more complex environment, you need to consider using Tivoli Access Manager. ----- Excerpt from IBM
