Object security depends on several inter-related security features.
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.
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).
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.
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.
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:
Important security decisions are made during Content Platform Engine installation and configuration. Among these are:
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.
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.
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.
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.