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 (such as services), applications, processes, and scripts, that have been explicitly granted access to the FileNet P8 domain can access its resources (such as objects, documents, workflows).

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 security identifiers (SIDs) for the user and for the groups that the user belongs to (recursively), and the SID for #AUTHENTICATED-USERS.

Each securable Content Platform 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 Platform 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 user to FileNet P8. The 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).

If your operating system is Microsoft Windows, do not use Windows service accounts for any user or group accounts required by FileNet P8.

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 Platform 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 permissions to everyone who can log in, irrespective of exactly who those users are at any given time. You should never assign the DENY permission to #AUTHENTICATED-USERS because this denies access to all accounts, even to administrators (because deny always takes precedence over allow). To correct a lockout of this type might require IBM assistance.

Importance of installation and configuration

Important security decisions are made during Content Platform Engine installation and configuration. Among these are:

• Which directory server will be used, where it is located, and how FileNet P8 will integrate with it. During configuration, you will select your directory service and then provide values for integration parameters. For example, for non-Windows Active Directory authentication you would instruct FileNet P8 whether or not to chase any referrals that FileNet P8 might find. (A referral is an attribute that specifies the URL that should be returned for an entry not belonging to the local tree.) You would provide this value based on your knowledge of your directory service topology and your specific authentication requirements.
• Whether you will plug in an SSO solution.
• Which users and groups in your directory service should be FileNet P8 administrators (there are several different administrative roles required by FileNet P8.) and which should be FileNet P8 users. Both types receive initial, default permissions (documented in Object Access) which you can later modify if necessary.
• How and where will SSL be used (if at all) between FileNet P8 components, associated applications, and supported platforms. It is a best practice to use SSL in production environments.

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 Platform 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.