Level: Intermediate Jim Hsu (jimhsu@us.ibm.com)IBM
Steve Nikopoulos (nikopoulos@iris.com)Associates in Westford
01 Jan 2001 This article introduces an exciting integration point between the IBM WebSphere Application Servers and the Lotus Domino Server that allows for single sign-on across a set of Web servers within an Internet domain. This mechanism is called Lightweight Third Party Authentication (LTPA) and is a way for servers to delegate authentication to a common third-party service.
The Standard and Advanced Editions of WebSphere Application Server 3.0 and higher currently
support LTPA. Lotus Domino Server version R5.05 is expected to have LTPA support as well,
making the integration story with the WebSphere Server that much more complete.
Common login across the WebSphere and Domino servers is an important integration point between
the two application servers. It is important because many enterprises now leverage the transactional
strengths of the WebSphere server with the collaborative advantages of the Domino server. This
results in Web applications that span both environments, having some portions of the Web site
in the WebSphere server that must exist along with other portions of the Web site served up by
the Domino server. Although such a Web site is really running on different application servers,
LTPA provides a built-in mechanism to let the user log into the site just once, preserving the
seamless appearance of the application.
LTPA architecture overview
Single sign-on is achieved through the use of an LTPA cookie that is common to both the WebSphere
and Domino servers. This means the browser client must have cookie support enabled for this to
work. LTPA allows WebSphere and Domino servers to authenticate to a common user directory using the
Lightweight Directory Access Protocol (LDAP). This allows the use of Domino's Name and Address Book
or any other LDAP V3-compatible user directory, such as Netscape Directory Server, IBM SecureWay
Directory, Novell Directory Server (NDS) or Active Directory. Figure 1 illustrates the single sign-on architecture.
Figure 1. Single sign-on using LTPA
To enable single sign-on, a common set of server encryption keys are created and exported across
all servers that run the application. When users first access the site, they are challenged to log
in with user ID and password. This creates a security credential token with the LTPA service, and a
cookie is written back to the browser. When the user later accesses another LTPA server in the same
domain, information in the shared cookie is used to re-establish the user security context with LTPA.
Hence, a second login prompt is unnecessary.
The LTPA cookie contains the following pieces of information:
- Cookie name: Always set to LtpaToken.
- Domain: Set to the Internet domain shared by all servers participating in single
sign-on (example: mycompany.com).
- Cookie expiration: Set to delete this cookie at the end of the browser's lifetime.
- Secure: Set to on to force the use of Secure Sockets Layer (SSL). There is an LTPA
configuration setting that creates cookies that are sent only through SSL.
- Cookie value: This is set to the LTPA token as described below.
The LTPA token is an encrypted string that contains the following pieces of information:
- User data: Typically set to the user ID but can be any user information used to uniquely
identify the user.
- Expiration time: Different from the Cookie expiration, this field is used to enforce a time
limit that starts from the moment of login and is unaffected by browser activity or inactivity.
The time limit is a configurable LTPA setting that defaults to 30 minutes.
- Digital signature: Used to validate the token.
Enabling LTPA in WebSphere
In the WebSphere Application Server, Standard and Advanced Editions version 3.0 and higher,
LTPA is enabled in the WebSphere server through the Administrative Console's Task Wizard, which
guides you through all the steps. WebSphere Application Server, Standard and Advanced Editions
version 3.5, uses the Administrative Console's Global Security Wizard. Figure 2 shows the Enable
LPTA screen in this wizard. The following security settings are configurable from here:
- Challenge type: Basic authentication, certificate, or forms-based
- Require SSL
- Enable LTPA
- Set LTPA Token expiration
- Generate LTPA keys
- Import LTPA keys
- Export LTPA keys
- Set LDAP user registry
Figure 2. Enabling LTPA in WebSphere Server
Enabling LTPA in Domino
Enabling LTPA in the Domino server is a three-step process, as outlined below. Figure 3
illustrates one of the configuration steps in the process.
Figure 3. Enabling LTPA in WebSphere Server
Step 1: Create the Web SSO configuration document.
- In the Domino Directory, select the Servers view.
- Select the Web... pull-down menu button.
- Select Create Web SSO Configuration.
- In the document, select the Keys... pull-down menu button.
- Initialize the Web SSO Configuration with the shared secret in one of two ways:
- Domino server only (no WebSphere servers participate in single sign-on). Select Create Domino SSO Key.
- Domino and WebSphere servers (single sign-on with WebSphere server 3.5).
- Select Import WebSphere LTPA Keys.
- Browse and select the WebSphere LTPA export file.
- Enter the password specified when generating the keys in WebSphere server.
- At this point, the document should update to reflect the information from the
export file.
- Configure the Token Expiration field.
- Enter the DNS domain (for example, mycompany.com) in the Token Domain field.
- Enter all participating servers in the Server Names field. Save the Web SSO Configuration
document. It is shown in the Web Configurations view.
Step 2: Enable single sign-on in the server document and basic authentication.
- Edit the Server document.
- Select Ports -> Internet Ports -> Web and enable Name and Password authentication for the HTTP
port.
- Select Internet Protocols -> Domino Web Engine -> Session authentication and select the
Multi-server option.
- Save the Server document.
Step 3: Start the HTTP task on the single sign-on enabled servers.
Start the HTTP Web servers. For example, from the Domino Server window, run load http. The
following message is displayed: HTTP: Successfully loaded Web SSO Configuration.
Revalidation with the LTPA token
The Domino and WebSphere server environments can pass around the LTPA token as shown in Figure 4.
For example, it is possible for a server-side application to use the LTPA token to revalidate with
downstream servers. Listing 1 shows how a servlet can extract the LTPA token and use it
to create a Domino session. To extract the LTPA token, find the cookie named LtpaToken and get
its value as a string object. This string now can be passed into the NotesFactory to create a
Notes session. The method is:
lotus.domino.NotesFactory.createSession
(host, ltpaToken)
|
Figure 4. Enabling LTPA in WebSphere Server
Conversely, it is possible to obtain a session token directly from a Notes session and use it
later to revalidate to another Domino server. The method calls are:
String sessionToken =
lotus.domino.Session.getSessionToken();
lotus.domino.NotesFactory.createSession(host,
sessionToken)
|
It is possible to use the LTPA credential out of the WebSphere Enterprise JavaBean (EJB)
environment to create a downstream authentication with the Domino server.
Listing 2
shows a sample EJB that creates a Domino session. The method call is:
lotus.domino.NotesFactory.createSession
(host, null)
|
Instead of passing a user ID and password pair or an LTPA token, we can pass the null object.
When null is passed, NotesFactory knows to look for the LTPA credentials from the EJB environment.
Maintaining security
Securing a publicly accessible Web site is a major concern for e-business. The administrator
must consider all the possible attacks that could potentially compromise the security of the site.
One way this might happen is if an outside party pilfers an LTPA token. The token itself could be
used wrongly to obtain the access permissions of a legitimate user, although any particular token
would be valid only during its expiration time limit. An SSL connection prevents the token from
being taken when it passes over the network. The client systems also need to be secured to prevent
someone from taking the token directly from a client machine.
Once a token is obtained, it could be used to discover the private server key by offline attacks.
The chance for success increases if the same private key is used for a long period of time, so the
security administrator should regularly regenerate the cryptographic keys used to secure the
servers.
Another way to increase security is to set up multiple firewalls that separate the Web server
from the enterprise applications. A discussion of the pros and cons for the different WebSphere
options for doing this can be found online at the
WebSphere Application Server site.
Finally, take measures to safeguard the passwords, especially the administrator's password.
Listing 1. Creating a Notes session from a servlet
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
import lotus.domino.*;
public class Example1 extends HttpServlet {
public void doGet (HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
Cookie[] cookies = null;
String sessionToken = null;
// Extract cookie named "LtpaToken"
try {
cookies = request.getCookies();
if (cookies == null)
return;
for (int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equals("LtpaToken"))
sessionToken = cookies[i].getValue();
}
}
catch (Exception e) {
e.printStackTrace();
}
if (sessionToken == null)
return;
// Use token to create Notes session
try {
NotesThread.sinitThread();
Session session =
NotesFactory.createSession(null, sessionToken);
// Add your code to use session here
}
catch (lotus.domino.NotesException e) {
e.printStackTrace();
}
finally {
lotus.domino.NotesThread.stermThread();
}
}
}
|
Listing 2. Creating a Notes session from an EJB
public class Example2 extends Object implements SessionBean {
...
public String getSessionUser() throws RemoteException
{
String result = "Example 2: ";
try {
// Create session from EJB environment
lotus.domino.Session s =
lotus.domino.NotesFactory.createSession(
"myserver.mydomain.com", null);
result += " -- Got Session for user: " +
s.getUserName();
}
catch (lotus.domino.NotesException ne) {
result += "-- " + ne.text;
result += "-- failed to get session for user";
}
return (String) result + " -- done";
}
}
|
Summary
The IBM WebSphere Application Server and Lotus Domino Server products have been improving
interoperability with each release. Single sign-on is one of the latest areas of integration. Domino
Server version R5.05 will contain the highly anticipated LTPA support and should be available by the
time this article is published.
The authors would like to thank Nataraj Nagaratnam for his assistance on details about LTPA.
Note: All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice and represent goals and objectives only.
Resources
About the authors  | | | Jim Hsu
is a member of the IBM Software Group Technology Center in Austin, Texas. Jim received
his bachelor's and master's degrees in electrical engineering and computer science from MIT. He
is interested in technologies with immediate widespread impact and has worked on the development
of Java programs that involve the Internet. You can reach him at jimhsu@us.ibm.com.
|
| | | Steve Nikopoulos works for Iris Associates in Westford, Massachusetts. He is a developer with the
Programmability team. Steve's most recent project has been the integration of the Domino and WebSphere servers. You can reach him at
nikopoulos@iris.com.
|
Rate this page
| 
