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.

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.

Back to top

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

Back to top

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.

Step 1: Create the Web SSO configuration document.

1. In the Domino Directory, select the Servers view.
2. Select the Web... pull-down menu button.
3. Select Create Web SSO Configuration.
4. In the document, select the Keys... pull-down menu button.
5. 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).
1. Select Import WebSphere LTPA Keys.
2. Browse and select the WebSphere LTPA export file.
3. Enter the password specified when generating the keys in WebSphere server.
4. At this point, the document should update to reflect the information from the export file.
6. Configure the Token Expiration field.
7. Enter the DNS domain (for example, mycompany.com) in the Token Domain field.
8. 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.

1. Edit the Server document.
2. Select Ports -> Internet Ports -> Web and enable Name and Password authentication for the HTTP port.
3. Select Internet Protocols -> Domino Web Engine -> Session authentication and select the Multi-server option.
4. 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.

Back to top

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)

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.

Back to top

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.

                


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();
    }
  }
}

                

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";
  }
} 

Back to top

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

• Trial downloads
  Get trial downloads of IBM Lotus software.
  
  
• For more information:
  • IBM Web application servers
  • Lotus Domino
  • Lotus Domino developer
  
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• LTPA architecture overview
• Enabling LTPA in WebSphere
• Enabling LTPA in Domino
• Revalidation with the LTPA token
• Maintaining security
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community