Single sign-on integrations via JAAS

The implementation of the Content Platform Engine server as a Java EE application allows it to take advantage of integrations between the Java EE application-server vendors and the leading single sign-on (SSO) solution providers such as IBM's Tivoli Access Manager and CA/Netegrity's SiteMinder. These are the two solutions that are currently qualified for end-to-end FileNet® P8 deployments.

If an SSO vendor has provided Java™ Authentication and Authorization Service (JAAS) Login Modules that work with a given application server, then the Content Platform Engine can support that single sign-on solution for custom Java-based applications. Support for SSO solutions in end-to-end environments is only supported for combinations that have been qualified by IBM. See the Identity Management section of the generated report titled Related software for FileNet Content Manager . Also see Single Sign-On Solutions for IBM FileNet P8 at ibm.com/redbooks for SSO configuration information.

Note the following limitations to integrating with SSO providers:

• JAAS-based SSO integration is available only to Java EE-based clients (clients who are able to perform a JAAS login). This type of client includes most of those that are browser-based and work with a Java EE-based presentation-tier server.
• JAAS-based SSO integration generally does not extend to .NET-based clients or pure Web-services-based clients.
• JAAS-based SSO integration is generally available only if the client's Java EE environment is supplied by the same application-server vendor hosting the Content Platform Engine application.
• The configuration of SSO solutions generally requires a high level of product-specific expertise. Before installing a FileNet P8 solution, customers must work with their SSO and Java EE application server vendors to correctly configure the single sign-on environment. The industry-leading SSO products have been designed to be highly flexible, supporting a wide range of credential types and configuration options. FileNet is only able to test a limited number of the infinite possible combinations of SSO vendor product configurations and application servers.
• In all cases, the third-party SSO product must be configured to work with the same underlying directory service (for example, Microsoft Active Directory and Novell e-Directory) used to resolve user and group credentials within FileNet P8.

The topics below discuss two leading single sign-on products with which FileNet P8 has done proof-of-concept integrations. Each of these products has configuration manuals that are literally thousands of pages in length, supporting many different credential types and authentication scenarios. The configurations presented below are intended to represent mere samples of what can be done.

CA/Netegrity SiteMinder Web Agent

The example presented in this topic focuses on one common Netegrity integration scenario. A browser-based client can authenticate through SiteMinder when HTTP requests are intercepted by a reverse proxy server running Netegrity's Site Minder Web Agent. In this scenario, a presentation layer application is hosted in a Java EE servlet or Java™Server Pages (JSP) environment. The clients think that they are accessing this application directly, but network access has actually been configured to flow through a reverse proxy server, which performs the authentication using a custom login page or some other mechanism.

Once the client is authenticated, all further requests will carry a SiteMinder SMSession token as an HTTP cookie. A SiteMinder Application Server Agent on the Web server extracts the SMSession token and performs a JAAS login on the client's behalf. The Web server can then make calls to Content Platform Engine. The JAAS Subject is propagated with each call. The diagram below illustrates the steps that occur in this scenario.

Remember: This example uses Netegrity products (for example, SiteMinder Application Server Agent Identity Asserter) which are specific to the WebLogic platform. Different components and product names would apply and the steps would be different if a different Java EE application server were in use.

HTTP requests intercepted by a reverse proxy server running Netegrity.

The following steps occur in this example:

1. The user issues a request for a Web page to the reverse proxy server. The first component to process this request is the SiteMinder Web Agent.
2. If the request does not contain a session token, the user is redirected to a custom login page, and prompted for credentials.
3. The user enters credentials, which are received by the Web Agent.
4. The SiteMinder Web Agent forwards the credentials to the SiteMinder Policy Server.
5. The SiteMinder Policy Server validates the credentials by retrieving user information from the user directory.
6. After the user is authenticated, the SiteMinder Policy Server returns a session token to the SiteMinder Web Agent.
7. The SiteMinder Web Agent saves the session token as a cookie on the user's machine.
8. The SiteMinder Web Agent adds to the request an HTTP header holding the session token and forwards the request to the reverse proxy server.
9. The reverse proxy server forwards the request to the JSP/servlet running on the application server.
10. The Java EE Web container hosting the JSP/servlet extracts the session token from the HTTP header and performs a JAAS login. JAAS authenticates the user by passing the session token to the SiteMinder ASA (Application Server Agent) Identity Asserter configured on the FileNet P8 web server.
11. The SiteMinder ASA Identity Asserter forwards the session token to the SiteMinder Policy Server.
12. If the SiteMinder Policy Server determines the session token is valid, it returns user information to the SiteMinder Identity Asserter.
13. The SiteMinder Identity Asserter adds principals to a JAAS Subject and returns it to the Web server.
14. The JSP/servlet calls the Content Platform Engine EJB on the Content Platform Engine server. The Web container propagates the JAAS Subject to the EJB container. The EJB container hosting the Content Platform Engine trusts this JAAS subject, because it has a trust relationship established with the Java EE application server hosting the FileNet P8 web server.
15. To perform authorization, Content Platform Engine retrieves user and group information from the user directory.
16. The Content Platform Engine EJB returns to the JSP/servlet.
17. The JSP or servlet builds an HTTP response and returns it to the proxy server.
18. The proxy server returns the response to the client.

When applets are used as a part of the client application, then the considerations in Support for Java applets must be taken into account to ensure that the applet behaves properly in the Netegrity environment.

WebSeal from IBM Tivoli Access Manager (TAM)

In the example presented in this topic, a browser-based client that has performed a login to a Windows domain in an Active Directory environment, uses an Internet Explorer (IE) browser to access a servlet or JSP page through an IBM WebSeal proxy. The JSP page calls Content Platform Engine through the Content Platform Engine Java API, over the EJB transport. This use case describes the use of Kerberos credentials and Windows integrated login to authenticate to WebSeal. Note, however, that any other browser-based authentication mechanism supported by WebSeal (for example, HTTP Basic or Forms-based authentication) will work just as well. The Windows Integrated Logon case below requires the use of Active Directory and the Microsoft Internet Explorer browser. Other browser-based scenarios, such as a forms-based authentication scenario, will work with other browsers and other directory services.

IE-based client in a Windows domain accesses a servlet or JSP page through an IBM WebSeal proxy.

The following steps occur in this graphic:

1. The client logs on to a Windows machine via an integrated login. The client provides user name and password credentials which are validated against Active Directory. The Microsoft Active Directory server also serves as a Kerberos Key Distribution Center (KDC). A Kerberos ticket granting ticket is issued.
2. The client uses a Microsoft Internet Explorer browser to access a JSP page.
3. Transparently to the client, the JSP request goes through a WebSeal proxy. WebSeal detects that the target Web site or Web page is a protected resource, and that the client is unauthenticated. WebSeal returns an HTTP Error response, with an HTTP header indicating that SPNEGO credentials are accepted. (Integrations with Kerberos-based authentication environments via the Simple and Protected GSS API Negotiation Mechanism (SPNEGO) standard are one type of perimeter authentication that is supported by many Java EE Web container implementations.)
4. Internet Explorer makes Kerberos calls to the KDC on the client's behalf, to obtain a Kerberos service ticket for the target resource.
5. The Kerberos ticket is placed into an HTTP header, per the SPNEGO specification, and the original request is resent with this header.
6. The WebSeal proxy again intercepts the request. This time it makes a call to Tivoli Access Manager (TAM) to validate the client's credentials.
7. TAM validates the Kerberos ticket and authenticates the caller. A TAM credential (an LTPA token) is returned to WebSeal.
8. WebSeal modifies the original HTTP request header to include a trusted server credential together with the TAM credential of the client and forwards the request to the target server.
9. On the WebSphere server hosting the JSP page, the request is intercepted by a TAM module: a Trust Association Interceptor (TAI). The trusted server is verified, the TAM credential is extracted from the request, and a JAAS login is performed on the client's behalf, using the TAM credential. A JAAS Subject is obtained for the client.
10. The JSP page calls a custom EJB in the same Java EE application (this step is not necessary in this scenario, and could be omitted.)
11. The custom EJB calls Content Platform Engine, through the Content Platform Engine Java API, and over the EJB transport. The client's JAAS Subject is automatically propagated to the Content Platform Engine server.

In this case, there is no client application code (the client is simply a browser accessing a Web page), nor is there any explicit authentication logic in the customer's JSP or EJB layers. WebSeal takes care of verifying the user's Kerberos credentials and generating a TAM credential based on them. TAM authentication modules on the WebSphere application server perform the JAAS login.

For more information about Tivoli Access Manager and related products, and how they might be used in a given customer environment, contact your service representative.

When applets are used as a part of the client application, then the considerations in Applets and reverse proxy servers must be taken into account, to ensure that the applet behaves properly in the WebSeal environment.