FileNet P8 Platform, Version 5.2.1            

Browser-based clients of Java EE application servers

Browser-based clients of Java EE-based application servers interact with servlets and Java™Server Pages (JSPs). To access a FileNet® P8 server, Java EE servlet-based applications must obtain a JAAS Subject that is valid in the Java EE EJB container that hosts the Content Platform Engine EJB. There are two paradigms that can be used to obtain this JAAS Subject: application-managed authentication and container-managed authentication.

Application-managed authentication

A servlet can make JAAS calls to perform its own JAAS login programmatically (see JAAS Overview). This approach can involve application-server-specific idiosyncrasies and configuration issues, but it is fairly standardized for the common user name and password case. To use application-managed authentication, each servlet deployed in the container must include logic that determines whether the user is authenticated. If the caller is authenticated, then its identity is determined by examining information in the user's session. Each servlet must perform some action (such as redirecting an unauthenticated user to a login page) that collects and verifies the user's credentials, handles errors, and manages the encoding of the authenticated identity into the user's session.

Container-managed authentication

One of a standard set of servlet authentication options can be specified in the Web application's deployment descriptor. In this case, the servlet container performs the JAAS login, based on the credentials that are supplied, relieving the application of this burden. 

Each Web application deployed in a servlet container can specify one of the following options, as defined in the servlet specification, that the container should use to authenticate users:

  • HTTP Basic Authentication (BASIC): The container requests the client browser to prompt the user for a user name and password, using a browser-specific dialog box. This option is defined by the HTTP specification. The user-supplied credentials are sent to the server for authentication. A secure transport must be used, as credentials are unencrypted. Few applications use this method, since the application's look and feel are not preserved, and the login prompt cannot be integrated into the application in a cohesive presentation.
  • HTTP Digest Authentication (DIGEST): Like HTTP Basic, but a digest (a one-way hash) of the password is sent instead of the password. This option is somewhat more secure, as the actual password is not compromised, but requires that the authentication mechanism that manages identities accept the password hash in a particular form, rather than the actual password. This is not possible in most real-world cases.
  • Forms-Based Authentication (FORM): Instead of asking the client browser to prompt for user name and password, the caller is redirected to an application-specific form to provide this information. This option allows customization of the look and feel of the login page and any error pages. It also requires a secure transport to protect the password.
  • HTTPS Client Authentication (CLIENT-CERT): This option requires each user to have a unique Public Key Certificate (PKC), and requires the use of an HTTPS (SSL) connection between the client and the server.

Note that while all four of the options above can be executed over an HTTPS connection (and, in fact that is a recommended best practice), only CLIENT-CERT actually requires an HTTPS connection. SSL is engaged through the configuration in the servlet descriptor of <transport-guarantee> as CONFIDENTIAL or INTEGRAL.

All of these technologies are forms of container-managed authentication, where the Java EE servlet container performs the JAAS authentication based on credentials obtained by a standard mechanism. The specification of one of these authentication mechanisms is a standard part of a servlet deployment descriptor. The specification and configuration of how the Java EE application server validates these credentials, however, is application-server-dependent. In an enterprise environment, an authentication mechanism must be provided to validate credentials against the enterprise identity management solution (either a directory service or SSO solution).

Once a caller has been authenticated by a Java EE servlet container, if the servlet subsequently calls an EJB, the Servlet Container is required to propagate the caller's identity (JAAS Subject) to the EJB. The diagram below illustrates the container-managed authentication case, using forms-based authentication to authenticate the caller against Active Directory:

Container-managed authentication, using a forms-based authentication option.

Container-managed authentication, using a forms-based authentication option.

The following steps occur in this graphic:

  1. A user attempts to access a servlet-based application.
  2. The Java EE application server redirects the user to a page that challenges for credentials.
  3. The user enters credentials and submits them to the server.
  4. The Java EE server validates the user's credentials via JAAS.
  5. The Java EE server creates JAAS Principal and Subject objects using the Active Directory JAAS Login Module, and places them in the user's session.
  6. The Java EE server redirects the user back to the application page that was originally requested.
  7. The servlet container looks for a user principal value available on the incoming request.
  8. Once invoked, the servlet makes a call to Content Platform Engine, and the user's JAAS Subject is propagated to Content Platform Engine's EJB container.
Perimeter authentication

In perimeter mode, the authentication process occurs outside of the Web container. An entity outside of the application server collects the users' credentials, validates them through proprietary mechanisms, and sends them onto the server in the form of an HTTP cookie. This is the mechanism used by SSO solutions to integrate with a Java EE Web application. Several examples of this mode are discussed in Single sign-on via JAAS.

The basic pattern is that a third-party proxy server intercepts the Web server requests and authenticates them using proprietary technology. A proprietary HTTP header is then added to the request (an SM-Session token in the Netegrity case, or an LTPA token in the Tivoli Access Manager case). When the request arrives at the Web server, the servlet container intercepts it, detects that it contains an SSO cookie, extracts the cookie, and invokes the SSO provider logic to perform a JAAS login, using SSO specific Login Modules, converting the contents of the cookie into a valid JAAS subject.

Perimeter authentication is considered as a form of container-managed authentication, even though authentication occurs outside of the container. Perimeter authentication is configured by selecting CLIENT-CERT as the container-managed authentication mechanism, and then performing some additional SSO provider-specific steps. The Web container extracts whatever data was present in the CLIENT-CERT cookie of the incoming request and passes it into the JAAS Login Modules that are configured for the Web application. A JAAS Login Module for a third-party SSO vendor can pass a proprietary token in this CLIENT-CERT field and then process that token in a Login Module the vendor provides.

Integration with Kerberos-based authentication environments via the Simple and Protected GSS API Negotiation Mechanism (SPNEGO) standard is one type of perimeter authentication used by many Java EE Web container implementations.



Last updated: October 2015
p8psn007.htm

© Copyright IBM Corporation 2015.