Application Engine and Workplace authentication

The Application Engine server hosts the Workplace Web application, Workplace Java™ applets, Process Engine applets, and application development tools. Application Engine is the presentation layer for both process and content. A number of different components run on the Application Engine. The sections below discuss how each of these components deals with authentication and single sign-on (SSO) integration.

Workplace application

This user Web application provides access to the document management and business process management capabilities of FileNet P8. Workplace also supports extended FileNet P8 capabilities such as forms management, records management, and portals. This is one example of a Java-based thin client solution, as described in the section Browser-based clients of J2EE™ application servers. (Most of the considerations discussed in that section apply for the Workplace application.)

Workplace is built using the Web Application Toolkit, and runs within a web container on a Java™ 2 Enterprise Edition (J2EE) application server, positioning it well to participate in the JAAS-based authentication framework of FileNet P8. The Web Application Toolkit is an extensible framework for building web applications. Programmers can use the toolkit to customize Workplace functionality or to build customized web applications.

The following topics discuss how each of the high-level authentication options discussed in Browser-based clients of J2EE application servers apply to the Workplace application.

Application-managed authentication

Application-managed authentication (the mode supported by earlier versions of Workplace) is basically a forms-based authentication, but the Workplace application performs the redirection of unauthenticated user requests to a log in page, and encodes the credentials supplied to the log in page, in the user's Java™Server Pages (JSP) session. This mode supports only user name and password credentials. The credentials collected from the Application Engine custom login page are used to programmatically perform a JAAS login. This mode is still the current default behavior of Workplace.

Container-managed authentication

In this mode, the application does not control the authentication process. The deployment descriptor for the application specifies the security constraints required to access application pages.

The deployment descriptor specifies the authentication method that should be used. The following standard methods defined by the Servlet specification (see Browser-based clients of J2EE application servers) are supported:

Perimeter authentication

This option is how most SSO products integrate with a J2EE application server. Client browsers running Workplace are redirected to a proxy server that authenticates the caller, and places a token in an HTTP header for them. When the request reaches the server, the container extracts the credentials and invokes SSO provider software that performs a JAAS login using them. This is known as a perimeter authentication because the actual authentication occurs outside of the container. Clients are already authenticated before their servlet requests arrive at the server. See JAVA-based client authentication and the examples in Single sign-on integrations via JAAS for more information.

Perimeter authentication lets Workplace leverage standard integrations between the application server vendors and the SSO technology vendors.

NOTE  Support for SSO in WorkPlace is limited to two specific combinations that IBM FileNet has qualified, as discussed in Single sign-on integrations via JAAS. If you are implementing SSO in an IBM Tivoli Access Manager WebSEAL 6.0 environment, you must configure WebSEAL for transparent junctions. For more information and configuration details, see your IBM product documentation.

Workplace applets

The Workplace applications include the following Java applets:

The section Applets and reverse proxy servers in the JAVA-Based Client Authentication (JAAS) topic discusses some of the concerns that must be taken into consideration when using Java applets across a reverse proxy server. The Workplace applets address these concerns in the current release.

The Workplace applets exchange XML data with the Application Engine server, and this XML data contains URL references that are not, by default, translated properly by reverse proxy servers. For this reason, some custom configuration work is required to get reverse proxy servers to work properly with the applets.

Application Integration clients

The Workplace Application Integration toolkit allows third-party client applications to integrate with Workplace. Windows-based applications, such as Microsoft Word and Microsoft Outlook, can leverage Application Integration COM components for this purpose. These COM components interact with the Application Integration servlets, sending XML requests over HTTP, and receiving XML responses.

Application Integration clients are not able to participate in single sign-on solutions (SSO); they are restricted to user name- and password-based authentication. Application Integration clients can co-exist with thin client applications that participate in an SSO solution. Application Engine can simultaneously support clients using container-managed authentication for SSO (for example, browser-based Workplace clients coming in through a reverse proxy server), and clients that are using application-managed authentication (such as Microsoft Office clients using the Application Integration Toolkit).

If Workplace is configured to use one of the supported end-to-end SSO solutions using a reverse proxy server, then the reverse proxy server must be configured to pass Application Integration traffic through unmodified, or the Application Integration clients must be configured to bypass the reverse proxy server, going directly to the Application Engine server.

FileNet P8 Portlets clients

FileNet P8 Platform includes the FileNet P8 Portlets product, a portal integration framework that provides commonly-required content and process functionality within third-party portal products. This framework includes portlets that provide user functionality such as authoring content, browsing features for accessing content, and providing a view of a user's inbox.

When portlets are used within Workplace in the My Workplace page, they will participate in the same SSO integrations as Workplace itself.
NOTE  For this scenario, Workplace must be configured for container-managed authentication.

To support SSO solutions within a third-party portal integration, the portlets container must first be configured for container-managed authentication. When this configuration is in place, the FileNet P8 portlets recognize that the container has taken care of authentication for them.

In cases where links from a portlet start Workplace (configured for container-managed authentication), an SSO infrastructure must also be in place to propagate the SSO provider identity tokens to the container that is hosting the application. Container-managed authentication is required to accept these tokens.

WebDAV clients

As of the current release, the WebDAV implementation has moved from Content Engine to Application Engine. WebDAV is now implemented as a separate servlet, residing in the same Web container as Workplace.

WebDAV is an HTTP-based API that does not present an HTML user interface to clients. For this reason, WebDAV is not able to take advantage of forms-based authentication schemes. In the current release, the WebDAV servlet must always be configured for application-managed authentication, managing its own user challenge process. The WebDAV servlet will be configured so that there is an application-level BASIC HTTP challenge/response mechanism used to gather WebDAV client credentials.

If Workplace is configured to use one of the supported end-to-end SSO solutions using a reverse proxy server, then the reverse proxy server must either be configured to pass WebDAV traffic through unmodified, or the WebDAV clients must be configured to bypass the reverse proxy server, going directly to the Application Engine server.

Application-managed authentication

If Application Engine is configured to use forms-based authentication (be it container-managed forms-based authentication, the default application-managed forms-based authentication, or a perimeter authentication scheme using a form to collect credentials) then WebDAV will not be able to participate in this. This will typically be the case, so the WebDAV servlet will be required to manage its own user challenge process. The WebDAV servlet will be configured so that there is an application-level BASIC HTTP challenge/response mechanism used to gather WebDAV client credentials.

Container-managed authentication

When Workplace is configured for a container-managed authentication using a non-HTML login method, such as BASIC or CLIENT-CERT authentication, then the WebDAV servlet can be configured as a resource protected by this mechanism as well.

If a perimeter authentication mechanism is in place that uses a non-HTML mechanism such as HTTP Basic authentication, then WebDAV clients can be authenticated by that perimeter mechanism and participate in an SSO environment.