Security overview

This topic describes FileNet P8 security architecture in general terms. It focuses primarily on inherent FileNet P8 features, rather than attempting to explain Java™ Authentication and Authorization Service (JAAS), Web Services, or the associated capabilities of the application servers and directory services on which FileNet P8 relies for authenticating users.

How does FileNet P8 secure its objects?

In FileNet P8, you secure data by specifying the directory service user context that controls who logs on to the system, setting access rights for those users, creating and applying security policies, and setting site preferences for user actions. Optionally, you can use technologies such as firewalls and proxy servers to control access to your network and Secure Sockets Layer (SSL) to provide data privacy.

FileNet P8 domain

Similar to other domain architectures, the FileNet P8 domain is a defined security context: only those users, groups, machine accounts (services, etc.), applications, processes, and scripts, that have been explicitly granted access to the FileNet P8 domain can access its resources (objects, documents, workflows, etc.).

How Access Control Works

After a user has been authenticated, but before he or she is allowed to perform any operations in an object store, a security token is generated specifically for that user's account that serves as a sort of internal passport. Like a passport, the security token is presented to an object at the time access is requested and it is used by the object to determine who the user is and whether or not the user is authorized for the type of access that is requested.

The security token contains the current and historical SIDs for the user and for the groups that the user belongs to (recursively), and the SID for #AUTHENTICATED-USERS.

Each securable Content Engine object has an associated security descriptor, part of which is the Access Control List (ACL). The ACL consists of a set of Access Control Entries (ACEs), also called permissions. Each permission specifies one security principal (user or group, via a SID), and an access mask for that SID. The access mask defines the specific operations that the grantee identified by the SID is allowed to perform. Each bit in the mask corresponds to a specific operation. If the bit is set, the security principal is authorized to perform that operation.

The above describes "normal" authorization, where markings have not been implemented. Markings provide another layer of authorization, described below.

Independently and dependently securable objects

Most Content Engine object classes are independently securable, meaning they are secured by their own ACL. Some are dependently securable, meaning that their security depends on some other object that they are associated with. A good example is the Content Element object, which can only exist in relationship to a Document object. The Document object is independently securable, while its various Content Elements take their security from the Document they are assigned to.

ACL and ACE model

Securable objects are secured by ACLs comprised of ACEs. Understanding the ACL/ACE model, and how security principals are determined and permissions granted is central to understanding how to design a secure FileNet P8 system.

First comes authentication, then comes authorization. Users are first authenticated to the FileNet P8 domain, which corresponds to a particular user context in the associated authentication provider. This determines that users are who they say they are, by validating their login user name and password. Thereafter, authenticated users are authorized to do certain things by the security of individual objects. For example, once the authentication process determines that you are in fact the user Bob who is known to the authentication provider, then the ACL on each securable object will determine what actions Bob can perform on the object (including nothing at all!)

Users and groups that are authenticated to access a FileNet P8 system arrive into the FileNet P8 security context with no inherent permissions of any sort. It is up to the object store administrator to assign FileNet P8-specific permissions to these accounts. For example, a user who is a Windows domain administrator is just like any end user to FileNet P8. The end user could be granted FileNet P8 object store administrative permissions while the Windows domain administrator could be granted nothing more than view or read-content permissions. In other words, the security context of the directory service or other software applications has no applicability to the FileNet P8 security model (and vice versa). The only relationship may be that a directory configuration (a set of authenticated user accounts) for a FileNet P8 domain may be defined as equal to a specific user context in a directory service).

Some other security features applied to ACEs and secured objects are:

Allow and deny   Each ACE that is present on an object's ACL is either allowed or denied the right to do certain things. For example, a particular class of documents could allow Alice to delete a document but deny Bob the same right. Following standard practice, deny always takes precedence over allow, which means you must set up ACLs carefully. If Alice is allowed access to a document as a user but belongs to a group that is denied access, then she will not have access to the object.

Inheritable depth   Certain rights are inheritable. FileNet P8 lets you configure whether they should not be inherited, or inherited only by objects that are immediate children (first generation only), or by all children.

Ownership   Most objects have an owner, who is usually the user who created the object. Similar to the Windows "built in" accounts, FileNet P8 automatically applies an internal "special” user account called the Creator-Owner, obviously suggesting that the creator of an object is its owner. System administrators can take ownership when necessary to change the object's security.

Authenticated users   The other "special" account, internally maintained by Content Engine, is the logical group #AUTHENTICATED-USERS. All users and groups who can potentially log in to FileNet P8 are automatically considered members of #AUTHENTICATED-USERS. This makes it the FileNet P8 equivalent of the Windows "Everyone" group, and makes it easy to allow or deny permissions to everyone who can log in, irrespective of exactly who those users are at any given time.

Importance of installation and configuration

As you would expect, important security decisions are made during Content Engine installation and configuration. Among these are:

Markings

Markings provide an additional, optional layer of security that is primarily designed for the records management marketplace, but which can also be applied by non-records management applications.

Auditing

FileNet P8's audit logging capabilities, while not being a security feature itself, is closely related to the topic of making sure your systems are properly secured and monitored. Content Engine also provides configurable trace logging.

Modification access required

If your installation requires finer-grained security, you can configure a modification access mask that specifies access rights needed to view or modify custom properties. These access rights take precedence over those applied to the object itself. Like markings, this security feature is designed for records management applications, but can be used by any application.

Access to content - querying and exporting

All files that represent document content and that have been stored in a FileNet P8 storage area (file storage area, fixed storage area, or database storage area) are completely protected by the FileNet P8 security model. Only those users who have been granted access to the content by a FileNet P8 application will have access, whether through content-based retrieval (CBR) queries, direct SQL queries, navigation of the network file structure containing a file storage area, etc.

Top of page

How is security applied?

Normally, an object's security is controlled or determined in four ways. (Markings, if they are used, would be a fifth way.) The following are brief descriptions.

Default instance security    As an integral part of the class and instance design, objects such as documents, folders, and events are instances of their class. The class includes, among other things, a property containing the default security permissions that will be applied to all instances of the class. This is the simplest method of applying security: the security design sets up the default security that all instances of a class should have, and then all objects based on that class will have the same default security.

Security parent and inheritance   Permissions can also be inherited from a parent object. Inheritance can take place between a class and its subclass, and between a folder and its containable objects (documents, custom objects, and other folders).

Security policies and security templates   Security policies contain security templates which let you automatically apply security to documents, folders, and custom objects. In the case of documents, security templates can be associated with one of the several versioning states that documents pass through (Released, Superseded, In Process, or Reservation). This powerful feature provides efficient application of fine-tuned security across many objects.

Directly applied security   Users who have sufficient permission can edit an object's security by directly adding or removing security principals, or by changing the existing permissions already granted.

Top of page

User authentication

All logins to FileNet P8 are done through the Java Authentication and Authorization Service (JAAS). Authentication is a process that occurs between a J2EE client application (for example, Workplace), a J2EE application server (either WebLogic, WebSphere®, or JBoss, hosting an instance of Content Engine), and one or more JAAS login modules. This process does not involve any FileNet code. Content Engine's ability to leverage JAAS for authentication means that if a single sign-on (SSO) provider writes a JAAS Login Module for a supported application server, then clients of FileNet P8 applications hosted in that application server can leverage that SSO solution. See the Authentication section for full information on FileNet P8 authentication architecture.

As a result, and unlike earlier releases of FileNet P8, the Content Engine installation process configures authentication and authorization separately even though these two configurations will often use the same information. Authorization takes place by means of a direct connection between Content Engine and one of the supported directory services; these are Windows Active Directory, ADAM, Sun Java System Directory Server, Novell eDirectory, and IBM® Tivoli®. See the Directory service providers section for details. The Hardware and Software requirements document contains the supported versions of these third-party products.

Process Engine now delegates authentication tasks to Content Engine. A client of the Process Engine authenticates with the Content Engine server, and then sends the credentials obtained from the Content Engine to the Process Engine server with each request. See Process Engine Authentication for details.

FileNet P8 authentication has been designed and extensively tested and optimized for directory servers with very large numbers of users. Optimization has particularly focused on FileNet P8's querying for accounts using pattern matching (starts with, exact match) and whether the search is optimized for short name or display name.

Configuring authentication

Two objects are required to map a directory service's naming context or "namespace" (a set of names accessible at a given node in the directory server's tree of accounts), to a FileNet P8 realm:

The following graphic shows the different configurations for authorization and authentication, for a single FileNet P8 domain:

Authorization and authentication configurations for a single FileNet P8 domain.

FileNet P8 supports multi-realm authentication provided the application server supports it. See Configure multiple realms for instructions on how to add additional realms following initial Content Engine installation.

Top of page

Security cache

For performance reasons, both Process Engine and Content Engine cache information on users, groups, and realms returned by the directory service. Cached security information may become stale as a result of changes made to the directory server. Each collection of users, groups and realms is subject to a "time to live" (TTL). From the time that a collection is first retrieved until the TTL interval has elapsed, requests for the same collection will return the cached information. Once the TTL has elapsed, the cached information will be discarded and fresh data will be obtained from the directory server.

Cache staleness may have the following effects:

Staleness does not affect the ability to use a recently added user or group name in programmatic calls, nor to log in as a recently added user. Also, staleness does not compromise the security of objects. The default TTL for Process Engine security cache is four hours. Content Engine has several default TTL settings. For information on how to set the Content Engine server caches, see FileNet P8 domain properties (Server Cache tab). For information on managing the Process Engine security cache, see Manage the Process Engine user cache.

Top of page

Security administrators and security tools

FileNet P8 provides several important security roles:

The Users and groups topic provides full reference information.

FileNet P8 provides the following tools for configuring security:

Enterprise Manager  This is the tool that system administrators will use in their daily work. Like similarly named tools provided by Microsoft® SQL Server and Oracle, Enterprise Manager gives system administrators easy access to most of the administrative and security features needed for Content Engine security configuration tasks.

Process Engine  Using the Process Engine Configuration Console, the Process Engine administrator can assign access rights to workflow rosters, work queues, and user queues. You will use another Process Engine tool, the Process Task Manager, to configure how the Process Engine integrates with the directory service.

Workplace and Workplace XT, and related applications (Application Integration, Records Manager, eForms)  The security context for applications is defined and maintained by a combination of Content Engine, Process Engine, and Workplace or Workplace XT. Consider the following examples:

Some security tasks can be completed by duly authorized users logged on to these applications, while others, including most of the more advanced tasks, are completed by an object store administrator running Enterprise Manager. Consult documentation provided for Workplace, Workplace XT, and the other out-of-the-box applications to see how much security-related functionality can be carried out by Application Engine administrators and advanced users.

Top of page