What are access rights?

Access rights are made up primarily of Access Control Entries (ACEs) that are organized into Access Control Lists (ACLs).

Most objects are independently securable, meaning they are secured by their own Access Control List (ACL). An object's ACL is the collection of all the Access Control Entries (ACEs) placed on it.

An object's access rights, also called permissions, 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) that uniquely identifies a security principal, a user or group that Content Platform Engine grants or denies access to. The value of each SID must be:

• Unique within the configured directory server, across all configured LDAP realms.
• Immutable. The directory server assigns a SID when it creates the user or group, and the SID value associated with a user or group must never change.

Most directory servers provide a built-in attribute as a stable and unique user and group identifier. Content Platform Engine uses these attributes as a default to obtain and store the user or group's SID. The values are typically the same for the user and group SID attributes, the UserUniqueIDAttribute and GroupUniqueIDAttribute properties respectively, but it is possible to specify different values for each property if required by your design. The following table shows the default values for each LDAP provider:

Table of Security Identifier attributes used by the Content Platform Engine for the listed directory servers.

Directory Server	UserUniqueIDAttribute default value	GroupUniqueIDAttribute default value
IBM Tivoli Directory Server	Ibm-entryuuid	Ibm-entryuuid
Novell eDirectory	guID	guID
Oracle Internet Directory	Orclguid	Orclguid
Oracle Directory Server Enterprise Edition (formerly known as Sun Java System Directory Server)	Nsuniqueid	Nsuniqueid
Active Directory (see Note)	objectSID (see Note)	objectSID (see Note)
Active Directory Lightweight Directory Service (AD LDS)	objectSID	objectSID

Note: When a user or group is migrated from one Windows domain to another, Active Directory assigns a new objectSID to the migrated user or group, and can add the previous SID to its sIDHistory property. In this case, Content Platform Engine's directory service provider for Active Directory is able to look up the sIDHistory to resolve a previous SID value that has been persisted in an ACL into a user or group. There is a slight overhead performing the sIDHistory lookup. Contact IBM Lab Services if you want assistance updating SID values in ACLs to the current objectSIDs; after such SID update service, sIDHistory lookup is not necessary.

You provide these property values while running Administration Console for Content Platform Engine's Create a Directory Configuration Wizard during initial installation. For more information, see the Directory Configuration Properties subsection of your directory server's topic at Directory service providers.

Because most of the default SID attributes are generated by the LDAP server itself during user or group creation, and because they are machine-dependent, SID value changes that might result because of activities such as backup, restore, moves, or duplication of the underlying LDAP server and hardware, can lead to complications. To introduce configuration flexibility and to avoid problems associated with a fixed SID attribute, you can choose non-default LDAP attributes, such as employee number, to function as the SID. The value of the attribute that you choose for your user and group IDs must be unique across the configured LDAP realms. Because the Content Platform Engine authorization process uses the attribute as the single identifier of a user or group in an LDAP repository, a non-unique value will cause authorization failures.

In addition to the requirements that they be unique and immutable (or static), non-default user or group SID values must be:

• Indexed, to improve performance of LDAP users or groups queries by SID.
• Less than or equal to 507 bytes. You should choose reasonably compact values for performance. (The lengths of default SID values range from approximately 16 to 36 bytes.)
• Returned as Java™ String via JNDI queries. You must use as SID attributes only those LDAP attributes that return Java String in the LDAP Java API. (There are, however, exceptions: if you prefer to assign default SID attributes in Active Directory or AD LDS using objectSID, or in eDirectory using guID, you can do so even though these return a Java byte[] type in the LDAP Java API.

If the value of a SID were to change, Content Platform Engine would consider the user or group to be a different security principal. For example, if the default SID attribute is used and you delete a user from the directory server, and then you recreate it with the same name and set of attributes but with a different SID value, that user would not be able to access the documents that it formerly had access to. This is because the directory server would have assigned it a new SID; the user's former Content Platform Engine permissions would somehow have to be reestablished.

The following are some common considerations for selecting a non-default SID attribute and managing SID values:

• Avoid using attributes containing family name or other information that can change due to personal events. An employee's family name might change as a result of a change in marital status or other reasons. Such a change obviously does not affect the employee's security role, but it would have the unintended effect of cause the employee's SID to change, leading losing access, explained above.
• Avoid using attributes containing work group name or other information that can change due to organizational events. A work group's name or reporting structure might change, but this does not necessarily affect the work group's or its members' security role. So these events should not impact SID values, and such attributes are not good SID attribute choices.
• The template or procedure to recreate or restore users and groups must ensure identical SID values, including the case of characters and the use of any filler spaces. Most LDAP servers can be configured to be case-insensitive and ignoring filler spaces, but this is not always the case. The best practice is to recreate or restore users and groups using static template values.
• SID values for distinct users and groups should differ by more than just the case of characters. Depending on the LDAP server and your configuration, your system might reject an entry if it contains the same value of an existing entry except for characters in different cases. Or it might add a system-generated prefix to make the new entry distinguishable. Either way leads to undesirable results.

The security or LDAP administrator is responsible for maintaining SID stability while performing administrative activities. In cases where SID values must change, such as when changing from one type of directory server or reorganizing the directory tree while using the default SID attribute, or migrating to use non-default SID attributes, the security administrator must reestablish Content Platform Engine permissions for the affected users and groups, or contact IBM Lab Services for assistance.

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 internal 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 Platform 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 server and Content Platform 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 Administration Console for Content Platform Engine or the security interface of an application. However, each provides a different security interface with different capabilities and behavior.