Authentication

Authentication is the act of verifying users' identities based on credentials that those users present. This section describes FileNet P8 authentication, which operates within Java™ 2 Enterprise Edition (J2EE)-established standards.

Supported authentication standards

The two standards at the core of the FileNet P8 authentication process are the Java Authentication and Authorization Service (JAAS) standard and the Web Services Security standard (WS-Security). The JAAS standard forms the framework for security interoperability in a J2EE environment, while the WS-Security standard forms the framework for security interoperability in the heterogeneous environment of clients and servers that communicate through Web services interfaces.

JAAS overview

Content Engine leverages JAAS for authentication (but not for authorization and it does not support the Java Security Manager). See the Directory Service Provider section for information about how Content Engine handles authorization.

JAAS provides a policy-based framework for reliably and securely determining who is invoking a Java application. Using this pluggable framework, applications like Content Engine can remain independent of the underlying authentication technologies. Likewise, application server vendors, authentication providers, and single sign-on (SSO) providers can package solutions that can be leveraged by all J2EE applications and clients. Customers can plug in new or updated SSO solutions without modifying already deployed client and server applications.

The Content Engine Enterprise Java Bean (EJB) resides within the J2EE Application Server's EJB container. The Content Engine EJB is therefore accessible only by authenticated callers, those who can pass any authorization checks that the administrator has placed on the EJB.

JAAS authentication

JAAS authentication

The client application obtains a JAAS Subject prior to calling the Content Engine Java API. Interactions with the Content Engine Java API then result in the Content Engine EJB being invoked. The client's JAAS subject is transparently sent to the J2EE application server with each EJB call. The application server validates the JAAS subject, and confirms the caller's identity before executing any code in the Content Engine EJB.

NOTE  For information about the authentication process used for a Web service-based client, see Web-Services-Based Client Authentication Via Ws-Security.

JAAS configurations

To use a J2EE-based application, a client must first perform a JAAS login. To do this, the client must specify a JAAS configuration (typically through a configuration file). The JAAS configuration specifies the authentication technologies (Login Modules) that will be used to verify the client's credentials.

A JAAS configuration file lists one entry for each configured application. Within an application's entry is a list of Login Modules for that application. Based on the contents of the configuration file, the JAAS framework dynamically determines which set of authentication technologies to invoke when a client application attempts to authenticate.

Each entry in a JAAS configuration is marked as Required, Requisite, Sufficient, or Optional. The authentication process for the client succeeds only if all Login Modules marked either Required or Requisite succeed. If no Required or Requisite Login Modules succeed, then at least one Sufficient or Optional Login Module must succeed.

JAAS login contexts

A J2EE client application must specify a JAAS configuration and a mechanism through which credentials can be obtained from a user at runtime. These two items constitute a JAAS Login Context. J2EE client applications use the Login Context to interact with JAAS and to authenticate themselves to a J2EE server.

JAAS login modules

JAAS-compliant Login Modules are implemented by authentication technology providers. J2EE application server vendors, such as BEA, IBM, and JBOSS, typically provide Login Modules for standard types of credentials, such as user name and password or X.509 certificate. SSO solution providers, such as CA Netegrity's SiteMinder, IBM's Tivoli Access Manager, and Oracle's CoreID, provide login modules for most of the market-leading J2EE application servers.

The JAAS Login Module is also the extensibility mechanism through which custom authentication solutions can be integrated with the FileNet P8 platform. A customer with a custom, non-standard authentication framework can integrate with FileNet P8 platform, by providing JAAS-compliant Login Modules that work with the J2EE application server that hosts the Content Engine application.

JAAS subjects

When a JAAS login has successfully completed, a JAAS Subject is returned to the caller. The Subject is a key J2EE class, which is transparently sent between J2EE clients and J2EE servers any time an EJB is invoked.

A JAAS Subject contains the set of JAAS principals (authenticated identities) and JAAS credentials (authentication data such as cryptographic keys) that result from the login process. Each Login Module that successfully authenticates the user updates the Subject with information about the user. A J2EE server application can examine the principals in the Subject to establish the caller's identity.

JAAS trust mechanisms

Trust mechanisms vary significantly from J2EE application server to J2EE application server and from Login Module to Login Module.

The JAAS Subject must either be signed by a party whom the application server trusts, or whom a configured server-side Login Module trusts (and a mechanism for configuring and verifying this trust relationship must exist), or credentials must be included in the JAAS Subject that a server-side Login Module can verify.

Each J2EE application server vendor has invented their own proprietary trust mechanisms. This is one factor that prevents interoperability of Login Modules between different J2EE implementations.

JAAS login module interoperability

JAAS Login Modules are generally not interoperable between different J2EE application server vendors. For this reason, FileNet P8 platform supports only homogeneous application server configurations: all Content Engine servers, as well as all Application Engine servers, or other J2EE presentation tier servers, must use the same J2EE application server as a host.

Using JAAS from a stand-alone Java client

For applications that reside in a J2EE container, the containers provide a set of JAAS integration capabilities that ease some of the interoperability issues discussed above.

For thick-client Java applications, however, the application must create a JAAS CallbackHandler to pass its credentials into a JAAS LoginContext. If the application relies on a user name and password paradigm, then the mechanism for doing this is well defined, and interoperability options are well known. For any other type of credential, the standard is not clear on what type of callbacks the application must use, nor how those callbacks should respond. In all cases, a stand-alone Java client must use Login Modules compatible with the J2EE application server it wishes to call.

Once a JAAS Subject has been obtained by the application, there are differences in how it indicates to the Java environment that the obtained Subject should be used when executing a given set of code, such as invoking an EJB. This is an area where the J2EE application server vendors had to improvise, and, as a result, different runtime calls are required for accessing different J2EE application servers.

WS-Security overview

A Web service is an XML-based interface to a system that is in conformance with the key Web services standards. Through standards compliance, Web services enable the development of service-oriented architectures, and allow heterogeneous systems to discover one another and interact. FileNet has developed Web service interfaces to the FileNet P8 Process Engine and Content Engine services, and supports the use of Business Process Execution Language (BPEL)-compliant Web services within a business process.

One of the key standards that defines a Web service is the WS-Security standard, developed by the OASIS standards body. WS-Security defines three main security mechanisms for Web services: security token propagation, message integrity, and message confidentiality. In this topic, we are only concerned with the first of these: security token propagation. WS-Security provides profiles that define how different types of security credentials are formatted and inserted into a Web service message.

Like JAAS, WS-Security is an extensible standard which supports multiple security token formats. The WS-Security specification describes how to encode a set of standard tokens as well as defining a general mechanism for encoding any binary token. However, the specifics of the standard tokens (the actual XML elements and attributes) are not defined in the WS-Security specification. They are defined in separate profiles, including the Username Token Profile, the X.509 Certificate Token Profile, the Security Assertion Markup Language (SAML) profile, the Kerberos profile, etc. It is these profiles that ensure interoperability between different implementations using the same token type. Later subtopics will describe how these profile types are used, or might be used, in the context of FileNet P8.

Unlike JAAS, WS-Security does not provide an execution environment that defines how to configure authentication on the client and server, or how a client can become authenticated, or how a security provider can implement and package a standards-compliant Login Module. WS-Security defines only the encoding of security tokens within the SOAP XML header. The sender of the token can perform an actual authentication, and send some proof of identity with a reference to a security authority who vouches for that identity (as in the Kerberos and X.509 certificate cases), or the sender can send raw credentials, which must be verified by the server (as in the username token case). The receiver of the token can process it in whatever way it sees fit.

When the Content Engine server receives a Web service request, the Content Engine Web service listener extracts the WS-Security header and performs a JAAS login based on its contents. If this JAAS login is successful, then the Web service listener passes the request onto the Content Engine EJB layer within the EJB container.

FileNet P8 Platform server authentication architecture

There are two primary servers in the FileNet P8 Platform:

The following subtopics describe how these servers perform authentication.

Content Engine authentication architecture

The next figure shows a high-level view of a FileNet P8 Content Engine server and some of the types of client applications that access it. Content Engine is packaged as a J2EE application, deployed on one or more J2EE application server instances. The key components of this application are:

The Web Service Listener and EJB layers are referred to as the two transport layers of Content Engine. All client requests enter Content Engine through one of these two transport layers.

CE and some types of client applications.

Content Engine and some types of client applications.

Process Engine authentication architecture

Process Engine delegates authentication operations to Content Engine. This arrangement is discussed in further detail in Process Engine Authentication.