What are access rights?

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 SID. The values are typically the same for the user and group SID attributes, the UserUniqueIDAttribute and GroupUniqueIDAttribute properties respectively. However, it is possible to specify different values for each property if required by your design.

The following table shows the supported directory servers and, for each directory server, the LDAP attributes that are used as defaults for the SID values.

Directory Server	UserUniqueIDAttribute default value	GroupUniqueIDAttribute default value
IBM Security 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
Oracle Unified Directory	Nsuniqueid Important: During directory service provider configuration, change this value from the default value to entryUUID.	Nsuniqueid Important: During directory service provider configuration, change this value from the default value to entryUUID.
Active Directory (see Note)	objectSID (see Note)	objectSID (see Note)
Active Directory Lightweight Directory Service (AD LDS)	objectSID	objectSID
SCIM Directory	id	id

Tip: 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, the Content Platform Engine 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 with updating SID values in ACLs to the current objectSIDs. After such an SID update service, sIDHistory lookup is not necessary.

You provide the values for the UserUniqueIDAttribute and GroupUniqueIDAttribute properties while running the Administration Console for Content Platform Engine Directory Configuration Wizard during initial installation. For more information, see the directory configuration property descriptions for your directory server at Directory service providers.

Because SID values are generated from the LDAP attribute values by the LDAP server itself during user or group creation, and because these LDAP attributes might be machine-dependent, SID values might be subject to change. These changes might result because of activities such as backup, restore, moves, or duplication of the underlying LDAP server and hardware, and they can lead to complications. Therefore, it is possible that in your organization the default LDAP attribute that is used to generate the SID for a particular directory server might not be the best option. To avoid problems associated with SID values that might change because of LDAP changes, you can choose non-default LDAP attributes, such as employee number, to function as the SID. The value of the LDAP 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 SIDs be unique and immutable, there are additional requirements that you must consider if you choose to use a non-default LDAP attribute for the user or group SID. The SID values must meet the following requirements:

• They must be indexed, to improve performance of queries for LDAP users or groups by SID.
• They must meet length limits that are compatible with your system configuration. Some FileNet® P8 and non FileNet P8 applications are sensitive to the size of the SID, which in turn makes those applications sensitive to the size of the LDAP attribute from which the SID is derived. The default LDAP attributes that are configured for each of the supported directory servers are tested extensively. Testing indicates that the default LDAP attributes are compatible with FileNet P8 applications and non FileNet P8 in common configurations. Therefore, it is strongly recommended to use the default LDAP attribute for your directory server. However, if a non-default LDAP attribute is chosen, then it must meet the following constraints:
  • If the Social Collaboration add-on features are in use to integrate the Content Platform Engine with other IBM products such as IBM® Connections, the chosen attribute must be less than or equal to 156 bytes in length if it is binary attribute, or 80 characters if it is a string.
  • If the workflow system is in use, the length must be less than or equal to 84 bytes or 44 characters.
  • If the previous limits do not apply then the chosen attribute must be less than or equal to 504 bytes or 254 characters. However, a value of this size is not recommended. A value of this size consumes a large amount of storage, for example, by ACLs. Values of this size could also cause problems if either of the previous features came into use at a later date. Therefore, values that fall within the previous limits are recommended.
• They must be returned as Java™ String via JNDI queries. For the SID values, you must use only those LDAP attributes that return Java String in the LDAP Java API. However, there are exceptions to this rule. If you prefer to use the default LDAP attributes in Active Directory or AD LDS using by objectSID, or in eDirectory by 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 the user 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.