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.
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.
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:
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.
The following steps occur in this graphic:
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.