About access rights

What are access rights?

Most objects are independently securable, meaning they are secured by their own Access Control List, or ACL. An object's ACL is the collection of all the access rights, or ACEs, placed on it. Access rights are also called permissions.

An object's access rights determine which users can view the object and what those users can do. For example, to see a folder a user needs at least the folder's View properties permission. To add a document to the folder, the user needs the Add to Folder permission.

Access rights vary by object and control all operations on that type of object. Documents (and only documents) have permissions that let the user make new versions of the document, whereas folders (and only folders) have an Add to Folder access right, and so on.

Security identifier (SID): Embedded into each ACE is a globally unique security identifier (SID), ensuring that it can be distinguished from all other possible accounts. FileNet P8 simply uses this SID and can display its value to properly authenticated users and system administrators.

Permissions and Levels: Each FileNet P8 ACE contains a set of permissions that the grantee is either allowed or denied. For example, Alice might be given permission to read a document (View Content) and look at the document's properties (View Properties). Bob might have these permissions and also have permission to add a document of a particular class (Create Instance) and delete a document (Delete). Unless these permissions are associated with Alice's ACE, she will not be able to carry out these actions on a particular document or class of documents.

In fact, each ACE has entries for all possible permissions for the particular object, with each permission set to either Allowed or Denied (or if not set at all the permission is implicitly denied). This is how Alice and Bob can have different permissions. The Create Instance permission might be marked Allow for Bob's ACE, and marked Deny for Alice's ACE. Deny settings have precedence over Allow settings. So, in Alice's case, even if she belongs to a group whose ACE indicates its members are allowed Create Instance permission, she will be denied that permission because of the Deny setting on her individual ACE.

Accounts reside in a directory server: FileNet P8 ACEs all represent accounts residing in one of the supported directory servers used for authorization. However, FileNet P8 creates and manages two special accounts, #CREATOR-OWNER and #AUTHENTICATED-USERS, which are not persisted in the authentication provider.

FileNet P8 uses LDAP, the Lightweight Directory Access Protocol, to provide accounts to Content Engine where they become associated with FileNet P8-specific permissions and other descriptors explained in this topic. The use of LDAP ensures that account information is safely encrypted in transit between the authentication provider or directory service and Content Engine. See Directory service provider integration for information about the supported directory servers.

Access Control Lists (ACLs): Once users are authenticated and logged onto a particular object store, their access to information, documents, workflows, etc. is controlled by security settings either on those objects or on objects that control the access to those objects. Each securable object has an Access Control List (ACL) that indicates who is granted and who is denied permissions to its properties and any associated content. An ACL can contain any number of grantees, which can be both users and groups. Each grantee's set of access permissions is stored as an access control entry (ACE).

Simply put, then, each ACL is a collection of ACEs whose purpose is to ensure that only those users and processes have the access that the system designers intend.

Understanding how ACEs and their associated permissions are inherited is an essential part of understanding and designing the security behavior for your application. Each ACE, besides indicating whether an access permission is allowed or denied, also contains information about the source of each permission. That is, a permission can either be applied directly, inherited from another object, or applied from a security template. The source has a direct effect on the permission's subsequent inheritance behavior, even determining whether it is inheritable to some other object. The next section describes these various aspects of an ACE.

Object store administrators can view and modify an object's security using either Enterprise Manager or the Workplace or Workplace XT applications. However, each provides a different security interface with different capabilities and behavior: How Workplace applications display security shows the application interface. Enterprise Manager's security editor illustrates the following data fields:

ACE name

The name of a user or group is associated to each ACE. This is in "principal name" format, which can vary depending on the underlying authentication service. Underlying the "Name" of the ACE is its fully qualified Distinguished Name or (if using Active Directory) its Principal name. Some FileNet P8 security interfaces will display this full name.

ACE source: Default, Direct, Inherited, Template

Every ACE has a "source" which you can view in Enterprise Manager's security editor:

Workplace and Workplace XT use the term "System" to identify Inherited and Template source types.

ACE security levels

A security "level" is a predefined collection of rights which simplify applying and administering individual rights. For example, the Full Control level for a document includes all possible document rights, whereas the Major Versioning level includes only those rights required to allow the user to perform the various tasks required to create a major version of a document. Documents, folders, custom objects, choice lists, and other securable objects all have their own predefined levels appropriate to the type of object. Levels can be viewed and assigned using the object's security editor. Applications can be designed to expose only the levels to users, or they can allow users to choose to assign levels or the individual rights. Enterprise Manager's security editor includes a "custom" level which is displayed if individual rights have been set that are different from the pre-designed rights-to-level mappings.

The topic in the Mapping security levels to individual access rights provides specific definitions of security levels.

Allow/Deny and order of evaluation

Each ACE has one access type: either Allow or Deny. When evaluating the access granted by a particular ACL, the current system applies ACEs in the following order of precedence (higher on the list takes precedence over lower):

ACE source and type
Display
Direct/Default Deny Direct/Default Deny
Direct/Default Allow Direct/Default Allow
Template Deny Template Deny
Template Allow Template Allow
Inherited Deny Inherited Deny
Inherited Allow Inherited Allow

You cannot remove or change an inherited access right, but you can override one by directly allowing or denying an access right. To edit an inherited access right, the administrator must modify the parent that is the source of the inherited access right.

Because Deny has precedence over Allow within each category (for example, a Template Deny takes precedence over a Template Allow), if you explicitly deny an access right to a group and explicitly allow it to a member of that group, the access right will be denied to the member.

Thus, if an ACL contained two ACEs that were identical in every respect except that one was an Inherited Deny and the other a Direct Allow, the Direct Allow would take precedence, with the result that the user would be allowed the ACE.