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:
- 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 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.
- 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 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.
- To perform authorization, Content Platform Engine retrieves user and
group information from the user directory.
- The Content Platform 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.
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:
- 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 Java EE 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 Java EE application
(this step is not necessary in this scenario, and could be omitted.)
- 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.