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).
Content Platform 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 Platform 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 Platform 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 Java EE applications and clients. Customers can plug in new or updated SSO solutions without modifying already deployed client and server applications.
The Content Platform Engine Enterprise Java Bean (EJB) resides within the Java EE Application Server's EJB container. The Content Platform 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
The client application obtains a JAAS Subject prior to calling the Content Platform Engine Java API. Interactions with the Content Platform Engine Java API then result in the Content Platform Engine EJB being invoked. The client's JAAS subject is transparently sent to the Java EE 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 Platform Engine EJB.
To use a Java EE-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.
A Java EE 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. Java EE client applications use the Login Context to interact with JAAS and to authenticate themselves to a Java EE server.
JAAS-compliant Login Modules are implemented by authentication technology providers. Java EE application server vendors 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 Java EE 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 Java EE application server that hosts the Content Platform Engine application.
When a JAAS login has successfully completed, a JAAS Subject is returned to the caller. The Subject is a key Java EE class, which is transparently sent between Java EE clients and Java EE 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.
Trust mechanisms vary significantly from Java EE application server to Java EE 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 Java EE application server vendor has invented their own proprietary trust mechanisms. This is one factor that prevents interoperability of Login Modules between different Java EE implementations.
JAAS login modules and JAAS Subjects are generally not interoperable between different Java EE application server vendors. For this reason, FileNet P8 platform supports only homogeneous application server configurations: all Content Platform Engine servers, as well as all IBM® Content Navigator servers, or other Java EE presentation tier servers, must use the same Java EE application server as a host, if those applications use the EJB transport.
For applications that reside in a Java EE 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 Java EE 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 Java EE application server vendors had to improvise, and, as a result, different runtime calls are required for accessing different Java EE application servers.
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 P8 has developed Web service interfaces to the Content Platform 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 Platform Engine server receives a Web service request, the Content Platform 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 Platform Engine EJB layer within the EJB container.