Understanding single sign-on (SSO) between

IBM® WebSphere® Portal and IBM Lotus®

Domino®

Charles Price
IBM Software Group
Advisory Software Engineer, Domino Portal Integration
Atlanta, 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®. Learn
the basics of how cookies are written to―and used in―Internet browsers, how the
cookies are used to enable SSO, and exactly what is in the token and why it's needed for
SSO between two servers. Included are specific details of where the WebSphere Portal
and Domino servers configure each part of the cookie used for SSO, the LTPAToken.

Table of Contents
1 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 Introduction
One of the most common issues when configuring IBM WebSphere Portal and IBM Lotus
Domino to work together is getting single sign-on (SSO) to work between the servers. In this
white paper we explain how SSO works; in other words, everything you ever wanted to know
about SSO but were afraid to ask, specifically focusing on SSO between WebSphere Portal
and Lotus Domino.

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

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

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

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

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

2.1 LTPAToken written to the browser

SSO between WebSphere Portal and Lotus Domino begins with a cookie called the
LTPAToken. But before we discuss how the LTPAToken works, we must discuss how
cookies work in general in the browser.

When you access an HTTP server, it can write cookies back to the browser to store
information 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 backend
server. 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 all
the 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 these
cookies are valid, and the name is under the Cookie Name column. You can also see what
the 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 three
important 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 are
accessing contains that domain. As a result, if you switch to mail.google.com, the cookies
will be passed again to this server. You could change the browser URL to anything that ends
with google.com; for example, servername.mail.atlanta.google.com would be passed the
cookies because it ends in google.com.

However, if you then change to www.yahoo.com, no cookies will be passed because no

cookies have www.yahoo.com or .yahoo.com as the domain. The reason for this is strictly
for security by the browser. You typically would not want information about yourself that's
entered 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 servers
in 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 SSO
working between the two servers, you will not be able to get SSO working, using those
URLs.

This is because the browser will never send the cookie created by WebSphere Portal to the
mail server, nor a cookie created by the mail server to WebSphere Portal. So why not set
the 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 how
you 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 the
name 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 wants
to use one of those cookies, it will need to know the name of the cookie to read from the
incoming http header.

For example, if google docs wants to know the email address of the user accessing the
server, it would know to look for the cookie named “GAUSR” and read the value of the
cookie (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 enable
SSO between them.

3 How the LTPAToken cookie is used between

WebSphere Portal and Lotus Domino
The cookie (LTPAToken) that's used to enable SSO between WebSphere Portal and Lotus
Domino uses the same three principles, each of which is explained in more detail in the
subsections below:

• same cookie name

• common domains
• same method for populating the cookie

3.1 Name of the cookie used for SSO between WebSphere Portal
and Lotus Domino
The name of the cookie will always be LTPAToken. There is no way to change or configure
this.

3.2 Cookie domain for SSO between WebSphere Portal and

Lotus Domino
If you clear out all cookies in Firefox and sign into WebSphere Portal, the cookies listed in
figure 2 will be written to your browser.

4
Figure 2. Cookies list

Here, three cookies, portalOpenFlyout, portalFlyoutIsOpen, and JSESSIONID are written to

the browser using the WebSphere Portal server hostname. These cookies will always be
written 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 we
discussed above, it's this fourth token that is used to enable SSO between WebSphere
Portal and Lotus Domino.

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

To see what domain your server is configured against, go to the WebSphere Application
Server Admin console (for example, https://dpi-dev.atlanta.ibm.com: 10041/ibm/console in
our environment), and select Security > Secure administration, applications and
infrastructure. 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 cookie
will 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 its
value 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 figure
6).

8
Figure 6. DNS Domain field

Note that the domain specified in WebSphere Portal or Lotus Domino must be part of the
URL 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 WebSphere

Portal, 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 written
to 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 WebSphere
Portal 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 Portal
server, 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 this
point WebSphere Portal expects the LTPAToken cookie to be passed to WebSphere Portal
to 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 the
log-in screen, and the cycle would continue until you changed the URL in the browser to
have .ibm.com.

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

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

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

Notice the content of the cookie used for SSO (LtpaToken). It's simply a long string of letters
and numbers, because the actual value of what's needed to enable SSO is encrypted by the
WebSphere Portal server. Once decrypted by the WebSphere Portal server, what's left are
the 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 realm

After the Domino or WebSphere Portal server decrypts the value of the token, the first thing
it looks at is the realm value in the token. It compares this realm to the realm value specified
on 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 with
the user directory. It is simply another way to verify that the token being passed by the
browser is authentic. On the Domino server this realm value is configured in the Web SSO
document. To see the value on your server:

1. Open Names.nsf in a Notes client.

2. Select Configuration > Web > Web Configurations
3. 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 Portal

server 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 value
with which the LDAP server and port security were enabled. So if you enabled security with
the server ldap.atlanta.ibm.com on port 389, the realm would be populated with
ldap.atlanta.ibm.com:389.

There was no way to change this, so the realm value in the Web SSO document's LDAP
Realm 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 the
realm value. Thus, if you enable security without realm support, WebSphere Portal works
just 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 in
the WebSphere Administration Server administrative console, and you can see what the
realm 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 the
Realm. If the parameter is not set, the default of WMMRealm will be used. If you want to
change this, simply create a new parameter called userRegistryRealm and populate it with
the value you want for the realm. You'll need to restart the WebSphere Portal server for the
change to take effect.

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

13
Figure 10. Admin console showing Custom user registry

If this field is set to “Lightweight Directory Access Protocol (LDAP) user registry,” security
was 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 and
port.
• If you add a realm to the existing configuration, the realm value will be set to
defaultWIMFileBasedRealm. WebSphere Portal 6.1 does not offer a way to configure the
realm value.

3.4 Token expiration date and time

Once the server has opened the token and verified that realm values match, it next checks
when the token is set to expire. When the server creates the LTPAToken, it looks at the
current time on the server and writes to the token the number of minutes for which the token
will be valid.

This is configured in the WebSphere Application Server Admin console in WebSphere

Portal and the Web SSO document in Lotus Domino. To see the number of minutes for
which a token is valid:

On WebSphere Portal 6.0.x and 6.1.x: Sign into the WebSphere Application Server Admin
console 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. The
default 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 say
you have set up SSO between WebSphere Portal and Lotus Domino and left the expiration
times as the defaults of 120 minutes and 30 minutes, respectively.

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

Let's now say the 120 minutes have passed, and the Domino server challenges you to
authenticate. Now the token is being written by the Domino server, so it is set to expire in 30
minutes. If you immediately change your browser to the WebSphere Portal server, now
WebSphere 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, after
which time the token will expire.

16
Different OS time zones. Another area of potential problems is when the server OS times
are in different time zones. For example, suppose you are having SSO issues and check the
OS clock. The times may be within seconds of each other, but if you look at the OS time
zone, you notice that WebSphere Portal is on EST (-5 GMT) while Domino is on PST (-8
GMT). 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 then
switch to the Domino server, which opens the token and reads the expiration time (10:00
EST, which translates to 7:00 PST), compares this to the current time on the server (8:00
PST), and sees the token has already expired.

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

3.5 Authenticated user's DN

After the realm value has been validated and the expiration time has been checked, the
server now pulls the final piece of information in the token, namely, the DN of the user for
which the token was created.

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

3.5.1 When WebSphere Portal receives the LTPAToken

Once WebSphere Portal has the user's DN, it will then look up the groups to which the user
belongs. It then compares the DN and list of groups to which the user has access with the
WebSphere Portal Access Control List (ACL) for the page and the portlets the user is
attempting to access.

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

3.5.2 When Lotus Domino receives the LTPAToken

Once Lotus Domino has the user's DN, before it looks up the groups, it does a lookup for the
user. Once it finds the user, it then takes this name to look up the groups. Similar to
WebSphere Portal, once the username and groups are determined, Lotus Domino
compares 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. The
easiest configuration for which SSO works correctly is when WebSphere Portal
authenticates with the same Domino Name and Address Book as the Domino server you are
attempting to access.

So let's say you sign into a WebSphere Portal server authenticating with a Domino LDAP
directory. The Person document for the user with which we are authenticating is shown in
figure 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 this
Person document, set the username to Dom User1/IBM, look up the groups based on Dom
User1/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, when
customers have two directories in their company. For instance, they may have a corporate
LDAP directory, such as IBM Directory Server, Active Directory, or SunOne LDAP; in
addition, 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 the
corporate LDAP directory, while the Domino resources use the Domino Directory. For
example, suppose WebSphere Portal authenticates with IBM Directory Server, and you
need SSO to the Domino mail files, authenticating with the domino Directory:

WebSphere Portal LDAP directory user Domino Directory

DN: uid=duser1,cn=users,dc=ibm,dc=com DN: CN=Dom User1,O=ibm
cn: Domino User1 cn: Dom User1
uid: duser1 uid: duser1
mail: duser1@acme.com mail: duser1@acme.com

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

To resolve the issue, we must make sure the lookup of that DN finds a match. In other
words, we must synchronize the two LDAP directories. You have two options in
synchronizing 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 administrator
you want to keep these directories in sync. If it's easier for the Domino Administrator to
update the Person documents, go with option 1. If it's easier for the corporate LDAP Admin
to update the person records, go with option 2.

If you have no preference as to the directory you synchronize, then there is one advantage
with option 2, Add the Domino DN to an attribute in the corporate LDAP directory. If users
will authenticate with both WebSphere Portal and Lotus Domino at times, using option 2 will
allow 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 are
synchronized between the directories. We will explain this further as we go into more detail
of how to configure each option:

3.5.3 Update Domino Directory with corporate LDAP DN

With this option you would add the corporate LDAP DN to the User name field in the Person
document (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 LDAP
delimiter, a comma (,), in the Domino Directory. Once the name is in this field, when the
Domino 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), you
will gain access just as if you signed into the mail file. SSO now works if you sign into
WebSphere Portal and change the browser a Domino database. However, he
reverse―signing into Domino and changing the URL to WebSphere Portal―will still not
work. 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 DN
to the token (CN=Dom User1,O=IBM). WebSphere Portal does not attempt to resolve the
name from the token to see if it's an alias. It simply checks this name against the
WebSphere Portal access control, and when it finds that CN=Dom User1,O=IBM doesn't
have access to the page, it will not allow access to the pages and portlets this user should
see.

To resolve this issue, add the corporate LDAP DN to the LTPA user name field on the
Administration tab of the Person document, in addition to the User name field on the Basic
tab (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 SSO
document, 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 of
writing the Domino DN, Domino will write the value of the LTPA user name field, in this case
uid=duser1,cn=users,dc=ibm,dc=com.

Now when WebSphere Portal opens the LTPAToken, it will find

uid=duser1,cn=users,dc=ibm,dc=com, which will be in the Portal Access Control. Therefore
SSO now works not only from WebSphere Portal to Lotus Domino, but also from Lotus
Domino to WebSphere Portal.

21
3.5.5 Update corporate LDAP directory with Domino DN
As discussed earlier, there is no need to update both directories, so if you have done option
1, this step is not necessary. If you decide to update the corporate LDAP directory, here is
the 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 add
the Domino DN of the user to this field. So the updated person record looks like this:

DN: uid=duser1,cn=users,dc=ibm,dc=com
cn: Domino User1
uid: duser1
mail: duser1@acme.com
notesdn: CN=Dom User1,O=ibm

Notice that the LDAP format of the name (comma separated) is used here. The rule of
thumb here is use the format the directory is accustomed to; that is, if updating Lotus
Domino, 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 to
search 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 communicate
with the corporate LDAP directory. This includes populating the “Attribute to be used as
Notes Distinguished Name” field (under Advanced Options) with the attribute in your LDAP
directory (notesdn in our example).

22
Figure 18. LDAP document

Next you must tell this server to used directory assistance. To do that, simply update the
Server document, adding the Directory Assistance database name to the Directory
Assistance 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. Lotus
Domino then requests that the corporate LDAP directory return the notesdn attribute and
use that value (CN=Dom User1/O=ibm) to look up groups and check ACL access. Since the
ACL 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 Lotus
Domino, but the reverse still does not work because the name in the token generated by
Lotus Domino is CN=Dom User1,O=ibm.

To address this, you need to update a field in the Directory Assistance document for the
corporate LDAP directory. Specifically, on the Basics tab update the “Attribute to be used in
an SSO token (map to notes LTPA_UsrNm)” field, setting it to $DN (see figure 20). This tells
the Domino server to use the notedn value to look up groups and check ACL access, but to
use 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” field
being 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 vice
versa.

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

5 Resources
Knowledge 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 author

Charlie Price is an Advisory Software Engineer in the IBM Software Group. He has six years
of experience in technical support for IBM Lotus software and two years in the test
organization, specializing in cross-product integration with Lotus, IBM, and other third-party
products. His areas of expertise include Lotus Domino Integration, Lotus Domino
administration, 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 system
administration, and an IBM Certified System Administrator for WebSphere® Portal. He holds
a degree in Mathematics Education from the University of Georgia and taught high school
mathematics 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, or
both.

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

26