| One of the first areas of integration between WebSphere and Domino application servers was user authentication. It was not long after developers started to build applications requiring secure access to both J2EE and Domino components that the need for shared user authentication, commonly referred to as "Single Sign-On (SSO)" was encountered . Basic SSO Between WAS and Domino The need for SSO surfaces when an application is designed with both Domino and J2EE components, which need to be accessed in a secure fashion. Let's consider the case where an application consists of a J2EE servlet and a Domino database, both of which are to be restricted to a certain group of users. If we protect both the servlet and database and set up basic (name and password) authentication for the users, we would end up with a situation where the users would be prompted for their name and password on the first access to either resource. The user is presented with multiple sign-on requests and is left wondering about the cohesiveness of the application. Ideally, we want authentication to be performed only once during a user's HTTP session, no matter how the resource is served ”that is, we want a single sign-on. How do WAS and Domino provide for SSO authentication? The answer is two-fold. First, there must be a way for WAS and Domino to share and convey the fact that a user has been authenticated, no matter which performed the authentication. Second, both WAS and Domino must share the information kept about the users so that authorization can be consistent. The first requirement is met by configuring WAS and Domino to use a special user authentication mechanism called Lightweight Third-Party Authentication (LTPA). The second requirement is met by configuring WAS and Domino to use a shared user directory (or "registry") via the Lightweight Directory Access Protocol (LDAP). The LTPA mechanism provides a secure means for conveying the fact that a user has already been authenticated. For Web applications, this mechanism must work in the context of a browser to Web server session ”and other contexts if possible. LTPA makes use of HTTP session "cookies" to store an encrypted set of user credentials at the browser and have it returned to the server on subsequent requests for protected resources. Both WAS and Domino can be configured to use LTPA, that is, to generate encrypted LTPA cookies and receive and decrypt LTPA cookies and to share the encryption keys needed for encrypting and decrypting . In Chapter 12, "Security and Single Sign-On," we discuss the use and configuration of LTPA by WAS and Domino in detail and discuss some of the issues that arise with LTPA. The requirement that WAS and Domino share a user directory for SSO is necessary so that authentication and authorization can be consistent. One needs to ensure that a user is authenticated and authorized in the same way no matter which application server performs it. Basing the shared user directory access on LDAP is a natural choice since LDAP is an open Internet standard that broadens the set of possible shared directory solutions. The use of LDAP enabled directories fits nicely with Domino as it has long provided LDAP access into and out from its own user directory. In Chapter 12, we present in detail various ways in which the shared user directory or registry can be configured and discuss some of the issues surrounding these configurations. SSO and WebSphere Portal Server With the advent of the WebSphere Portal Server (WPS) product, the need for SSO support is even more critical and, at the same time, more challenging. By design, the portal user interface displays separate applications in separate frames of the Web pages, called "portlets," and each portlet may be driven by a separate application on the server. Without SSO support, a portal would become a maze of different sign-on pop-ups and authentication mechanisms as the user navigates among the portlets. The portal server and portlet architecture make it easier for disparate applications to be integrated at the browser, but, at the same time, make it more challenging for the designer and developer to provide the necessary integration on the server. A prime example of a portal environment is the WPS-based IBM Lotus Workplace product. The Lotus Workplace portal brings together Domino, Lotus Instant Messaging (formerly known as Sametime), and QuickPlace products, along with J2EE applications, to form an e-mail and collaboration portal. Each of these Lotus products can be run as a stand-alone application with its own user directory and authentication/authorization mechanism. Bringing them all under a single portal requires an even broader scope for the SSO requirements of shared user directories and authentication. In the case of the original release of Lotus Workplace, the fact that all of the applications are Domino-based provides us a common set of tools, namely LTPA and LDAP, to help us achieve SSO. But as we discuss further in Chapter 12, even this common base can lead to difficulties in implementation. For clarification , it should be noted that beginning with Lotus Workplace 1.1, there is no longer the need to connect to a Lotus Sametime/Domino server for Web conferencing and Instant Messaging. In Lotus Workplace 1.1 those components are now J2EE-based applications running on top of the WebSphere server. Appendix F gives details on Lotus Workplace 1.1. At the time this book was written, the latest version of the WebSphere Portal Server (V5.02 Extended Edition) still required separate Sametime and QuickPlace servers. Other SSO Mechanisms There are other approaches to providing SSO support than those offered directly by WAS and Domino. These solutions usually involve a dedicated authentication component that can manage user authentication across a wide range of products and plug into the product-specific authentication mechanisms. The dedicated authentication solutions also provide a wider range of authentication mechanisms that can be presented to the user, such as hardware-based authentication, smart cards, certificates, and so on. IBM offers a product within the Tivoli product suite, which is focused on managing security among a broad range of enterprise applications. The product, Tivoli Access Manager (TAM), provides for enterprise-wide access control, security policy management, authorization, and auditing functions. TAM is most applicable for customers who want to centralize security among heterogeneous Web applications (beyond WPS and Domino) or those who desire flexible authentication alternatives (tokens, certificates, and so on), enhanced access control mechanisms (time-of-day checking, day-of-week-checking, etc.), and for customers who have selected TAM for their overall security and SSO architecture. TAM contains a component called WebSEAL that provides a Web access proxy function; that is, it intercepts Web requests from the open Internet, authenticates and validates the requests, and then forwards the requests to the application servers on secure network connections. WebSEAL is designed to sit in the network layer exposed to the Internet where it handles user authentication for all Web resource requests. The WebSEAL proxy provides a module interface, called a "junction," which allows specific implementations to be used for common functions. By plugging in different modules to junctions, WebSEAL can be configured to use different mechanisms to perform the user authentication for the Web request and authentication/authorization to the application servers. WebSEAL provides an LTPA junction so that SSO can be achieved among WebSphere and Domino application servers fronted by a WebSEAL proxy server. At the time of this writing, the LTPA junction is the only means available for achieving SSO with WebSEAL, WebSphere, and Domino. (Refer to IBM Redbook Technote TIPS0331 at www.redbooks.ibm.com.) |
