Understanding single sign-on (SSO) betweenIBM® WebSphere® Portal and IBM Lotus®Domino®

Charles PriceIBM Software GroupAdvisory Software Engineer, Domino Portal IntegrationAtlanta, GA

February 2009

© Copyright International Business Machines Corporation 2009. All rights reserved.

Abstract: This white paper provides an in-depth explanation of how the single sign-on(SSO) feature works between IBM® WebSphere® Portal and Lotus® Domino®. Learnthe basics of how cookies are written to―and used in―Internet browsers, how thecookies are used to enable SSO, and exactly what is in the token and why it's needed forSSO between two servers. Included are specific details of where the WebSphere Portaland Domino servers configure each part of the cookie used for SSO, the LTPAToken.

Table of Contents1 Introduction ....................................................................................................................... 2 2 SSO Basics ........................................................................................................................ 2

2.1 LTPAToken written to the browser ........................................................................... 2 2.2 How is the domain/site used? .................................................................................... 3 2.3 How is the cookie name and value used? .................................................................. 4

3 How the LTPAToken cookie is used between WebSphere Portal and Lotus Domino ..... 4 3.1 Name of the cookie used for SSO between WebSphere Portal and Lotus Domino .. 4 3.2 Cookie domain for SSO between WebSphere Portal and Lotus Domino ................. 4 3.3 How is the LTPAToken populated, and how does that allow for SSO? ................. 10 3.4 Token expiration date and time ............................................................................... 14 3.5 Authenticated user's DN .......................................................................................... 17

4 Conclusion ...................................................................................................................... 25 5 Resources ........................................................................................................................ 25 6 About the author ............................................................................................................. 26

1

1 IntroductionOne of the most common issues when configuring IBM WebSphere Portal and IBM LotusDomino to work together is getting single sign-on (SSO) to work between the servers. In thiswhite paper we explain how SSO works; in other words, everything you ever wanted to knowabout SSO but were afraid to ask, specifically focusing on SSO between WebSphere Portaland Lotus Domino.

2 SSO BasicsIn its simplest form SSO lets a user sign into one server in your environment, and then notneed to sign in again to any other servers as long as that browser is open. SSO isessentially a three-step process:

1. User signs into WebSphere Portal, and a cookie named LTPAToken is written to thebrowser (where “LTPA” = Lightweight Third-party Authentication).

2. User changes URL to the Domino server, and the browser passes the cookie to theDomino server.

3. Domino reads the LTPAToken and determines access to the database you areattempting to access.

In the following sections we go into more detail on exactly what happens during these threesteps.

2.1 LTPAToken written to the browserSSO between WebSphere Portal and Lotus Domino begins with a cookie called theLTPAToken. But before we discuss how the LTPAToken works, we must discuss howcookies work in general in the browser.

When you access an HTTP server, it can write cookies back to the browser to storeinformation about the browser that is accessing the server. For example, if you go to www.google.com and sign in, six cookies are written to the browser (LSID, SID,GoogleAccountsLocale_session, PREF, and GAUSR).

These cookies are written with at least three pieces of information:

• the domain for which the cookie is valid (.google.com, in this case)• the name of the cookie (LSID, SID, etc.)• the value or content in the cookie

The domain is used to tell the browser when it should pass the cookies to the backendserver. You can see all this information using a Firefox browser by selecting Tools >Options, clicking on the Privacy tab, and then clicking on Show Cookies. A window with allthe cookies currently in the browser is displayed (see figure 1).

You can see the six cookies here. Under the site column is the domain for which thesecookies are valid, and the name is under the Cookie Name column. You can also see whatthe cookie is populated with by looking at the Content: field.

2

Figure 1. List of all cookies on your computer

Note that the cookie domain or site, the cookie name, and the cookie content are the threeimportant parts of the cookie and are integral to how it is used.

2.2 How is the domain/site used?The only time the browser will send the cookies is if the domain of the server you areaccessing contains that domain. As a result, if you switch to mail.google.com, the cookieswill be passed again to this server. You could change the browser URL to anything that endswith google.com; for example, servername.mail.atlanta.google.com would be passed thecookies because it ends in google.com.

However, if you then change to www.yahoo.com, no cookies will be passed because nocookies have www.yahoo.com or .yahoo.com as the domain. The reason for this is strictlyfor security by the browser. You typically would not want information about yourself that'sentered into one server (mail.google.com) sent to a different server (www.yahoo.com).

IBM Technical Support is often asked whether it's possible to set up SSO between serversin different domains. For example, suppose the URL to WebSphere Portal is portal.ibm.com,and the URL to the mail server is mail.lotus.com. Because we rely on cookies to get SSOworking between the two servers, you will not be able to get SSO working, using thoseURLs.

This is because the browser will never send the cookie created by WebSphere Portal to themail server, nor a cookie created by the mail server to WebSphere Portal. So why not setthe cookie to .com since both URLs above (portal.ibm.com and mail.lotus.com) end in .com?

3

The browsers will not allow this because a cookie must be at least two values in length.

So, for example, .ibm.com, lotus.com, .atlanta.ibm.com, .mail.atlanta.ibm.com will all work,but .com, .net, .us, .edu, .gov are all invalid.

For those of you who are in an environment that has multiple domains, we will discuss howyou can address this later in the paper.

2.3 How is the cookie name and value used?Once a cookie is written to the browser and passed to a server, the server must know thename of the cookie, in order to use it. As you can see from the google mail example above,when you sign in, five cookies are written to the browser. If another google application wantsto use one of those cookies, it will need to know the name of the cookie to read from theincoming http header.

For example, if google docs wants to know the email address of the user accessing theserver, it would know to look for the cookie named “GAUSR” and read the value of thecookie (cpricejr@gmail.com).

So for two Web sites to share information through cookies, the two servers must

• be in a common domain• agree to use the same cookie name• agree on how to populate the cookie value

Let's now look at exactly how WebSphere Portal and Lotus Domino use cookies to enableSSO between them.

3 How the LTPAToken cookie is used betweenWebSphere Portal and Lotus DominoThe cookie (LTPAToken) that's used to enable SSO between WebSphere Portal and LotusDomino uses the same three principles, each of which is explained in more detail in thesubsections below:

• same cookie name• common domains• same method for populating the cookie

3.1 Name of the cookie used for SSO between WebSphere Portaland Lotus DominoThe name of the cookie will always be LTPAToken. There is no way to change or configurethis.

3.2 Cookie domain for SSO between WebSphere Portal andLotus DominoIf you clear out all cookies in Firefox and sign into WebSphere Portal, the cookies listed infigure 2 will be written to your browser.

4

Figure 2. Cookies list

Here, three cookies, portalOpenFlyout, portalFlyoutIsOpen, and JSESSIONID are written tothe browser using the WebSphere Portal server hostname. These cookies will always bewritten to the browser using the hostname specified in the URL in the browser address bar(dpi-dev.atlanta.ibm.com in figure 2 above).

Note, however, that the fourth cookie, LtpaToken, is written to the domain .ibm.com. As wediscussed above, it's this fourth token that is used to enable SSO between WebSpherePortal and Lotus Domino.

The token domain (ibm.com) or site is set by the server writing the cookie to the browser. Ona WebSphere Portal server this is a configurable parameter in the WebSphere ApplicationServer Admin console.

To see what domain your server is configured against, go to the WebSphere ApplicationServer Admin console (for example, https://dpi-dev.atlanta.ibm.com: 10041/ibm/console inour environment), and select Security > Secure administration, applications andinfrastructure. Expand Web security, and select single sign-on (SSO), as shown in figure 3.

5

Figure 3. WebSphere Application Server Admin console

The domain name field (see figure 4) is where you specify the domain with which the cookiewill be set (.ibm.com, in our environment).

6

Figure 4. Setting the domain name

On the Domino server, the domain name is specified in the Web SSO document. To see itsvalue on your server, do the following:

1. Open Names.nsf in a Lotus Notes® client.2. Select Configuration > Web > Web Configurations.3. Expand Web SSO configurations and open the Web SSO document for your server (see

figure 5).

7

Figure 5. Web SSO document

In this document the cookie domain name is specified in the DNS Domain field (see figure6).

8

Figure 6. DNS Domain field

Note that the domain specified in WebSphere Portal or Lotus Domino must be part of theURL you use in the browser to access the WebSphere Portal or Domino servers.

For example, we use dpi-dev.atlanta.ibm.com as the hostname to access WebSpherePortal, so we could set the domain name to .atlanta.ibm.com or .ibm.com. If we now use dpi-dev.lotus.com to access our WebSphere Portal server, an LTPAToken would still be writtento the browser, but the domain used would be dpi-dev.lotus.com.

The reason for this goes back to how cookies work in the first place. If the WebSpherePortal server wrote the cookie with .ibm.com, but the browser was at the URL dpi-dev.lotus.com, the browser would never send the cookie back to the WebSphere Portalserver, causing you to never be able to log in.

You would sign in, the WebSphere Portal server would accept the username and password,then write the LTPAToken cookie to the browser and send you to the home page. At thispoint WebSphere Portal expects the LTPAToken cookie to be passed to WebSphere Portalto determine what access you have to the home page.

The browser would look for any .lotus.com cookies and, finding none, would pass nothing.The WebSphere Portal server would not receive a cookie, so it would send you back to thelog-in screen, and the cycle would continue until you changed the URL in the browser tohave .ibm.com.

9

To get around this, WebSphere Portal will use the hostname in the browser to write thetoken, if that hostname does not contain the domain name specified in the WebSphereApplication Server Admin console.

Lotus Domino, on the other hand, does not use this workaround. So if we access our mailserver using mail.lotus.com, but specify .ibm.com in the Web SSO document, the log-inpage will simply refresh on the page each time we try to sign in.

3.3 How is the LTPAToken populated, and how does that allowfor SSO?Let's go back and look at the cookies you have in your browser after you sign-in toWebSphere Portal (recall figure 2).

Notice the content of the cookie used for SSO (LtpaToken). It's simply a long string of lettersand numbers, because the actual value of what's needed to enable SSO is encrypted by theWebSphere Portal server. Once decrypted by the WebSphere Portal server, what's left arethe following three pieces of information to complete SSO:

• Token Realm• Token expiration date and time• Distinguished Name (DN) of user who signed into WebSphere Portal to generate the

token

3.3.1 Token realmAfter the Domino or WebSphere Portal server decrypts the value of the token, the first thingit looks at is the realm value in the token. It compares this realm to the realm value specifiedon the server and, if they match, the token is accepted.

This value is simply a string value and has no bearing on how the servers authenticate withthe user directory. It is simply another way to verify that the token being passed by thebrowser is authentic. On the Domino server this realm value is configured in the Web SSOdocument. To see the value on your server:

1. Open Names.nsf in a Notes client.2. Select Configuration > Web > Web Configurations3. Expand Web SSO configurations, and open the Web SSO document for your server (see

figure 7).

10

Figure 7. Web SSO document

In this document the realm value is specified in the LDAP Realm field (see figure 8).

11

Figure 8. LDAP Realm field

On our test server the realm is set to defaultWIMFileBasedRealm. On a WebSphere Portalserver the realm value depends on (1) how security was enabled and (2) what version it is.

In WebSphere Portal 5 and earlier versions the realm value would always be the valuewith which the LDAP server and port security were enabled. So if you enabled security withthe server ldap.atlanta.ibm.com on port 389, the realm would be populated withldap.atlanta.ibm.com:389.

There was no way to change this, so the realm value in the Web SSO document's LDAPRealm value had to be populated with ldap.atlanta.ibm.com:389.

In WebSphere Portal 6 a change was made to let administrators configure the value of therealm value. Thus, if you enable security without realm support, WebSphere Portal worksjust as it did in version 5; that is, the realm will be ldap server: ldap port(ldap.atlanta.ibm.com:389 in our example).

If, however, you enable security with realm support, the value of the realm is configurable inthe WebSphere Administration Server administrative console, and you can see what therealm value is by using the Admin console, as follows:

For WebSphere Portal 6.0.x: Select Security > Global Security > User Registry > Custom >Custom Properties (see figure 9).

12

Figure 9. Admin console showing userRegistryRealm parameter

If configured, you will have a property called userRegistryRealm containing the value of theRealm. If the parameter is not set, the default of WMMRealm will be used. If you want tochange this, simply create a new parameter called userRegistryRealm and populate it withthe value you want for the realm. You'll need to restart the WebSphere Portal server for thechange to take effect.

NOTE: If you are not sure how security was enabled, check it by going to the WebSphereApplication Server Administration Console > Security > Global Security. If the Active userregistry field is set to Custom user registry, the security was enabled with realm support (seefigure 10).

13

Figure 10. Admin console showing Custom user registry

If this field is set to “Lightweight Directory Access Protocol (LDAP) user registry,” securitywas enabled without realm support.

For WebSphere Portal 6.1.x: As with version 6.0, there are two ways to enable security:

• If you configure a standalone LDAP user registry, the realm will be the ldap server andport.

• If you add a realm to the existing configuration, the realm value will be set todefaultWIMFileBasedRealm. WebSphere Portal 6.1 does not offer a way to configure therealm value.

3.4 Token expiration date and timeOnce the server has opened the token and verified that realm values match, it next checkswhen the token is set to expire. When the server creates the LTPAToken, it looks at thecurrent time on the server and writes to the token the number of minutes for which the tokenwill be valid.

This is configured in the WebSphere Application Server Admin console in WebSpherePortal and the Web SSO document in Lotus Domino. To see the number of minutes forwhich a token is valid:

On WebSphere Portal 6.0.x and 6.1.x: Sign into the WebSphere Application Server Adminconsole to see the expiration time.

On Lotus Domino: On the Domino server the token expiration time is configured in the

14

Web SSO document. To see the value on your server:

1. Open Names.nsf in a Notes client.2. Go to Configuration > Web > Web Configurations.3. Expand Web SSO configurations and open the Web SSO Configuration document for

your server (see figure 11).

Figure 11. Navigating to Web SSO Configuration document

In this document (see figure 12) the token expiration time is specified in the Expiration(minutes) field. In our test environment the timeout is set to 120 minutes, or 2 hours. Thedefault is 30 minutes.

15

Figure 12. Web SSO Configuration document showing Expiration field

3.4.1 Important notes about expiration times

Server creates the token. It's worth emphasizing exactly how this expiration time works;specifically, it's the server that creates the token that sets the expiration time. So let's sayyou have set up SSO between WebSphere Portal and Lotus Domino and left the expirationtimes as the defaults of 120 minutes and 30 minutes, respectively.

If you sign into WebSphere Portal and then immediately change the browser to the Dominoserver, you may think that, because you are then on the Domino server, you will only have30 minutes until the token expires and you must sign in again. This is not true; instead, thetoken will be set by the WebSphere Portal server, so you will have 120 minutes before youare asked to sign in again.

Let's now say the 120 minutes have passed, and the Domino server challenges you toauthenticate. Now the token is being written by the Domino server, so it is set to expire in 30minutes. If you immediately change your browser to the WebSphere Portal server, nowWebSphere Portal is set to expire in 120 minutes, but because the token was set by the Domino server, you will be able to navigate WebSphere Portal for 30 minutes, afterwhich time the token will expire.

16

Different OS time zones. Another area of potential problems is when the server OS timesare in different time zones. For example, suppose you are having SSO issues and check theOS clock. The times may be within seconds of each other, but if you look at the OS timezone, you notice that WebSphere Portal is on EST (-5 GMT) while Domino is on PST (-8GMT). So if the clock on both machines shows 8:00, then 8:00 EST is 5:00 PST.

So you log into WebSphere Portal, which sets the token to expire at 10:00 EST. You thenswitch to the Domino server, which opens the token and reads the expiration time (10:00EST, which translates to 7:00 PST), compares this to the current time on the server (8:00PST), and sees the token has already expired.

To avoid the issue, either set both machines to EST or set the Domino server to the correctPST time (5:00).

3.5 Authenticated user's DNAfter the realm value has been validated and the expiration time has been checked, theserver now pulls the final piece of information in the token, namely, the DN of the user forwhich the token was created.

This is the key piece of information needed from the token and allows for SSO. Once theserver has the DN, the next steps are slightly different, depending on whether Lotus Dominoor WebSphere Portal receives the token.

3.5.1 When WebSphere Portal receives the LTPATokenOnce WebSphere Portal has the user's DN, it will then look up the groups to which the userbelongs. It then compares the DN and list of groups to which the user has access with theWebSphere Portal Access Control List (ACL) for the page and the portlets the user isattempting to access.

This is quite similar to the process when you sign in, except WebSphere Portal does notlook up the user and does not compare any password, as no passwords are stored in thetoken.

3.5.2 When Lotus Domino receives the LTPATokenOnce Lotus Domino has the user's DN, before it looks up the groups, it does a lookup for theuser. Once it finds the user, it then takes this name to look up the groups. Similar toWebSphere Portal, once the username and groups are determined, Lotus Dominocompares this to the ACL of the database the user is attempting to access.

Let's go into a bit more detail in the case of the Domino server, using an example. Theeasiest configuration for which SSO works correctly is when WebSphere Portalauthenticates with the same Domino Name and Address Book as the Domino server you areattempting to access.

So let's say you sign into a WebSphere Portal server authenticating with a Domino LDAPdirectory. The Person document for the user with which we are authenticating is shown infigure 13. Here the DN in the LTPAToken would be in the LDAP format of Dom User1/IBM,where CN=Dom User1, O=IBM.

17

Figure 13. Person document

When Lotus Domino looks up CN=Dom User1,O=IBM in the $users view, it will find thisPerson document, set the username to Dom User1/IBM, look up the groups based on DomUser1/IBM, and then compare this to the ACL of the database you are attempting to access,say, the mail file (see figure 14).

Figure 14. Mail file ACL

So in this case the user would be given access to the mail file with Manager access.

18

Now let's look at the case in which this functionality becomes extremely helpful; that is, whencustomers have two directories in their company. For instance, they may have a corporateLDAP directory, such as IBM Directory Server, Active Directory, or SunOne LDAP; inaddition, they may have the Domino Directory containing the same group of users.

In this environment it's common for the WebSphere Portal server to authenticate with thecorporate LDAP directory, while the Domino resources use the Domino Directory. Forexample, suppose WebSphere Portal authenticates with IBM Directory Server, and youneed SSO to the Domino mail files, authenticating with the domino Directory:

WebSphere Portal LDAP directory user Domino DirectoryDN: uid=duser1,cn=users,dc=ibm,dc=comcn: Domino User1uid: duser1mail: duser1@acme.com

DN: CN=Dom User1,O=ibmcn: Dom User1uid: duser1mail: duser1@acme.com

In this configuration, if you sign into WebSphere Portal, the DN in the LTPAToken in LotusDomino would contain uid=duser1,cn=users,dc=ibm,dc=com. Lotus Domino would attemptto look up that user, but would find no matches as this DN exists only in the corporate LDAPdirectory.

To resolve the issue, we must make sure the lookup of that DN finds a match. In otherwords, we must synchronize the two LDAP directories. You have two options insynchronizing the directories; either:

1. Add the corporate DN to the Domino Person document, or 2. Add the Domino DN to an attribute in the corporate LDAP directory.

Customers often ask what option is best. The decision comes down to which administratoryou want to keep these directories in sync. If it's easier for the Domino Administrator toupdate the Person documents, go with option 1. If it's easier for the corporate LDAP Adminto update the person records, go with option 2.

If you have no preference as to the directory you synchronize, then there is one advantagewith option 2, Add the Domino DN to an attribute in the corporate LDAP directory. If userswill authenticate with both WebSphere Portal and Lotus Domino at times, using option 2 willallow them to always use the same name and password to sign into both servers.

If you go with option 1, you would also need to ensure the log-in attribute and password aresynchronized between the directories. We will explain this further as we go into more detailof how to configure each option:

3.5.3 Update Domino Directory with corporate LDAP DNWith this option you would add the corporate LDAP DN to the User name field in the Persondocument (see figure 15).

19

Figure 15. LDAP DN as the User name

Note that you should use the Domino delimiter, a forward slash (/), instead of the LDAPdelimiter, a comma (,), in the Domino Directory. Once the name is in this field, when theDomino server looks up the user's DN from the LTPAToken(uid=duser1,cn=users,dc=ibm,dc=com), it will find this entry and begin using Dom User1/IBM to find groups and check ACL access.

Because the ACL contains the name that Domino knows for the user (Dom User1/IBM), youwill gain access just as if you signed into the mail file. SSO now works if you sign intoWebSphere Portal and change the browser a Domino database. However, hereverse―signing into Domino and changing the URL to WebSphere Portal―will still notwork. This is due to what WebSphere Portal does once it receives a DN.

In this step, we signed into Domino first. Domino looks up the user and adds the Domino DNto the token (CN=Dom User1,O=IBM). WebSphere Portal does not attempt to resolve thename from the token to see if it's an alias. It simply checks this name against theWebSphere Portal access control, and when it finds that CN=Dom User1,O=IBM doesn'thave access to the page, it will not allow access to the pages and portlets this user shouldsee.

To resolve this issue, add the corporate LDAP DN to the LTPA user name field on theAdministration tab of the Person document, in addition to the User name field on the Basictab (see figure 16).

20

Figure 16. Corporate LDAP DN in LTPA user name field

When this is populated, the “Map names in LTPA tokens” field is Enabled in the Web SSOdocument, as seen in figure 17.

Figure 17. Map names in LTPA tokens field Enabled

With this, Domino changes the way it writes the DN to the LTPAToken; that is, instead ofwriting the Domino DN, Domino will write the value of the LTPA user name field, in this caseuid=duser1,cn=users,dc=ibm,dc=com.

Now when WebSphere Portal opens the LTPAToken, it will finduid=duser1,cn=users,dc=ibm,dc=com, which will be in the Portal Access Control. ThereforeSSO now works not only from WebSphere Portal to Lotus Domino, but also from LotusDomino to WebSphere Portal.

21

3.5.5 Update corporate LDAP directory with Domino DNAs discussed earlier, there is no need to update both directories, so if you have done option1, this step is not necessary. If you decide to update the corporate LDAP directory, here isthe high-level view of what's done, and why:

First you must decide what attribute will contain the Domino DN of the user. For example,let's decide to extend the user's schema and add an attribute called notesdn. Then we addthe Domino DN of the user to this field. So the updated person record looks like this:

DN: uid=duser1,cn=users,dc=ibm,dc=comcn: Domino User1uid: duser1mail: duser1@acme.comnotesdn: CN=Dom User1,O=ibm

Notice that the LDAP format of the name (comma separated) is used here. The rule ofthumb here is use the format the directory is accustomed to; that is, if updating LotusDomino, use the slash (/) separator, and if updating LDAP, use the comma (,) separator.

Once the LDAP directory has been updated, you now need to tell Lotus Domino how tosearch this directory and what attribute contains the Domino DN of the user. To do this,create a Directory Assistance database and create an LDAP document (see figure 18).

On the Basics tab, populate all the information on how Lotus Domino should communicatewith the corporate LDAP directory. This includes populating the “Attribute to be used asNotes Distinguished Name” field (under Advanced Options) with the attribute in your LDAPdirectory (notesdn in our example).

22

Figure 18. LDAP document

Next you must tell this server to used directory assistance. To do that, simply update theServer document, adding the Directory Assistance database name to the DirectoryAssistance database name field, as seen in figure 19.

23

Figure 19. Server doc showing Directory Assistance database name field

Now, when Lotus Domino receives the corporate LDAP DN in the LTPAToken(uid=duser1,cn=users,dc=ibm,dc=com), it will look for the name in the Domino directory.When it doesn't find a match, it will then send the name to the directories specified in da.nsf.

Because this is going against the corporate LDAP directory, the name will resolve. LotusDomino then requests that the corporate LDAP directory return the notesdn attribute anduse that value (CN=Dom User1/O=ibm) to look up groups and check ACL access. Since theACL contains Dom User1/ibm, you will gain access to the mail file.

Again, we run into the issue where SSO now works from WebSphere Portal to LotusDomino, but the reverse still does not work because the name in the token generated byLotus Domino is CN=Dom User1,O=ibm.

To address this, you need to update a field in the Directory Assistance document for thecorporate LDAP directory. Specifically, on the Basics tab update the “Attribute to be used inan SSO token (map to notes LTPA_UsrNm)” field, setting it to $DN (see figure 20). This tellsthe Domino server to use the notedn value to look up groups and check ACL access, but touse the LDAP directories DN when creating the LTPAToken.

24

Figure 20. Directory Assistance document

Also, don't forget that this works in conjunction with the “Map names in LTPA tokens” fieldbeing set to Enabled in the Web SSO document (recall figure 17).

With that set, SSO will now work both from WebSphere Portal to Lotus Domino and viceversa.

4 ConclusionHopefully, you now have a good understanding of how single sign-on works between IBMWebSphere Portal and IBM Lotus Domino. You should fully grasp how we use theLtpaToken cookie to enable SSO between WebSphere Portal and Lotus Domino, as well asthe limitations therein due to how cookies work in the browser. No matter what environmentyou have, the instructions in this paper should enable you to integrate WebSphere Portaland Lotus Domino and quickly unlock the collaboration features of WebSphere Portal.

5 ResourcesKnowledge Base document #1158269, “Troubleshooting WebSphere Portal, Domino

25

Extended Products, and Domino SSO issues”:http://www.ibm.com/support/docview.wss?rs=899&uid=swg21158269

developerWorks Lotus Notes and Domino product page:http://www.ibm.com/developerworks/lotus/products/notesdomino/

developerWorks WebSphere product page:http://www.ibm.com/developerworks/websphere

Lotus Notes and Domino wiki:http://www-10.lotus.com/ldd/dominowiki.nsf

WebSphere Portal family wiki:http://www-10.lotus.com/ldd/portalwiki.nsf

developerWorks article, “How to configure SSO with LTPA for IBM Lotus Connections 2.0”:http://www.ibm.com/developerworks/lotus/library/connections-sso/

6 About the authorCharlie Price is an Advisory Software Engineer in the IBM Software Group. He has six yearsof experience in technical support for IBM Lotus software and two years in the testorganization, specializing in cross-product integration with Lotus, IBM, and other third-partyproducts. His areas of expertise include Lotus Domino Integration, Lotus Dominoadministration, the Lotus collaborative portlets, and Lotus Quickr.

He is an IBM Certified Associate System Administrator - Lotus Collaborative Solutions(administering QuickPlace®), a Principal Certified Lotus Professional for Domino systemadministration, and an IBM Certified System Administrator for WebSphere® Portal. He holdsa degree in Mathematics Education from the University of Georgia and taught high schoolmathematics for three years before joining IBM.

Trademarks• Domino, IBM, Lotus, Notes, QuickPlace, and WebSphere are trademarks or

registered trademarks of IBM Corporation in the United States, other countries, orboth.

• Other company, product, and service names may be trademarks or service marks ofothers.

26