Single sign-on integrations via JAAS
The implementation of the FileNet
P8 Content Engine server as a Java™ 2 Enterprise Edition (J2EE)
application allows it to take advantage of integrations between the J2EE application-server
vendors (such as IBM and BEA) 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 FileNet P8 Content Engine can support that single sign-on
solution for custom Java-based applications. Support for SSO solutions in end-to-end
environments using the P8 Application Engine is only supported for combinations
that have been qualified by IBM. See the IBM FileNet P8 Hardware
and Software Requirements for a list of qualified solutions.
To download this guide from the IBM support page,
see Accessing
IBM FileNet Documentation .
Note the following limitations to integrating with SSO providers:
- JAAS-based SSO integration is available only to J2EE-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 J2EE-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 J2EE environment is supplied by the same application-server
vendor hosting the Content 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 J2EE 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
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 J2EE 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 Engine. The
JAAS Subject is propagated with each call. The diagram below illustrates the
steps that occur in this scenario.
NOTE 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 J2EE application server were in use.

HTTP
requests intercepted by a reverse proxy server running Netegrity.
The following steps occur in this example:
- 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.
- If the request does not contain a session token, the user
is redirected to a custom login page, and prompted for credentials.
- The user enters credentials, which are received by the Web
Agent.
- The SiteMinder Web Agent forwards the credentials to the SiteMinder
Policy Server.
- The SiteMinder Policy Server validates the credentials by
retrieving user information from the user directory.
- After the user is authenticated, the SiteMinder Policy Server
returns a session token to the SiteMinder Web Agent.
- The SiteMinder Web Agent saves the session token as a cookie
on the user's machine.
- The SiteMinder Web Agent adds to the request an HTTP header
holding the session token and forwards the request to the reverse proxy server.
- The reverse proxy server forwards the request to the JSP/servlet
running on the application server.
-
The J2EE 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 P8 Application Engine server.
- The SiteMinder ASA Identity Asserter forwards the session token to the
SiteMinder Policy Server.
- If the SiteMinder Policy Server determines the session token is valid,
it
returns user information to the SiteMinder Identity Asserter.
- The SiteMinder Identity Asserter adds principals to a JAAS
Subject and returns it to the Web server.
- The JSP/servlet calls the P8 Content Engine EJB on the P8 Content Engine
server. The Web container propagates the JAAS Subject to the EJB
container. The EJB container hosting the P8 Content Engine trusts this JAAS
subject, because it has a trust relationship established with the J2EE
application server hosting the P8 Application Engine.
- To perform authorization, Content Engine retrieves user
and group information from the user directory.
- The Content Engine EJB returns to the JSP/servlet.
- The JSP or servlet builds an HTTP response and returns it to
the proxy server.
- The proxy server returns the response to the client.
Note that 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 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 Engine through the
Content 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:
- 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.
- The client uses a Microsoft Internet Explorer browser to access
a JSP page.
- 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 J2EE Web
container implementations.)
- Internet Explorer makes Kerberos calls to the KDC on the client's
behalf, to obtain a Kerberos service ticket for the target resource.
- The Kerberos ticket is placed into an HTTP header, per the
SPNEGO specification, and the original request is resent with this header.
- The WebSeal proxy again intercepts the request. This time
it makes a call to Tivoli Access Manager (TAM) to validate the client's credentials.
- TAM validates the Kerberos ticket and authenticates the caller.
A TAM credential (an LTPA token) is returned to WebSeal.
- 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.
- 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.
- The JSP page calls a custom EJB in the same J2EE application
(this step is not necessary in this scenario, and could be omitted.)
- The custom EJB calls Content Engine, through the
Content Engine Java API, and over the EJB transport. The client's JAAS Subject
is automatically propagated to the Content 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.
Note that 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.