This chapter provides information on Content Server access control lists (ACLs), which are lists of users, groups, or roles with permission to access or interact with a content item.
This chapter covers the following topics:
In addition to the standard Content Server security roles, security groups, and accounts, the Content Server can be configured to support access control lists (ACLs). An access control list is a list of users, groups, or Enterprise roles with permission to access or interact with a content item.
When access control list security is configured, three new fields are available for use in several locations in the interface, including checking in content items, updating content items, and searching for content items. The fields are:
User Access List
Group Access List
Role Access List
After the access control list security feature is configured for Content Server, you can use Oracle Platform Security Services (OPSS) to manage the access control lists, including the Oracle Access Manager (OAM) Authentication provider, which works with the Oracle WebLogic Server domain. For information, see Oracle Fusion Middleware Application Security Guide and Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
Content Server access control lists are supported in Oracle Secure Enterprise Search, and users can perform searches using access control list information. For more information, see Section 10.2.
Note:
When using the RoleEntityACL component with Oracle WebCenter Content: Records, the component does not affect any retention objects such as categories or records folders. Therefore, the ability to use ACLs on a Records role is not enabled on the category creation page or folder creation page even if the RoleEntityACL component is enabled. The role ACL functionality is, however, enabled on the content check-in page.
Caution:
The NeedToKnow (NtkDocDisclosure, or NTK) component supports customization for Content Server security; however, it may not work together with access control lists because of conflicting security models. For more information, see Appendix B.
To set up access control lists (ACLs), configure the following items in Content Server:
To support user and group access control lists, the following configuration variables must be set in the Content Server config.cfg file:
UseEntitySecurity: Set this variable to true.
SpecialAuthGroups: Set this variable to the name of the Content Server security group that will use the ACL security. Out-of-the-box Content Server has only two security groups: Public and Secure. Usually a site will create a third security group for which ACL security is to be applied.
Enter the variables in the Additional Configuration Variables field of the General Configuration page, which you can access from the Administration interface for your Content Server instance.
The configuration variable UseEntitySecurity=true sets Content Server security to always evaluate the user and group access control lists for content items. This parameter creates two metadata fields: xClbraUserList and xClbraAliasList.
To support the enterprise role access control list, the RoleEntityACL component must be enabled in Content Server.
This component is installed (disabled) by default with Content Server. Use the Content Server advanced component manager to enable the component.
The RoleEntityACL component configures Content Server to work with other applications to evaluate the enterprise role access control list. This component turns on the UseRoleSecurity parameter, which sets Content Server security to integrate enterprise role access list information for content items. The UseRoleSecurity parameter creates the xClbraRoleList metadata field.
If you want non-administrator users to be able to use the Add User menu to select users for the User Access List when checking in content items, set the configuration variable AllowQuerySafeUserColumns=true. If this variable is not set, no values are displayed in the menu for the User Access List field.
Access control lists are computed based on the values in three metadata fields: xClbraUserList, xClbraAliasList, and xClbraRoleList. When the metadata values are populated with user, group, or enterprise role names and permissions to a content item, they affect which users, groups, and enterprise roles are allowed to search or act on the content item.
These metadata fields are populated from the User Access List, Group Access List, and Role Access List fields, which can be viewed or accessed when checking in a content item, updating a content item, and performing a search using the expanded form.
Administrators can use scripts to specify values to populate the metadata fields for the access lists.
The xClbraUserList metadata field is used to specify users and their permissions for a content item.
The following list describes requirements for administrators to specify xClbraUserList values in scripts:
Each user name is preceded by an ampersand (&) symbol.
Each user's permissions follow the user name in parentheses.
User names are separated by commas.
Example: xClbraUserList=&sysadmin(RWDA),&user1(RW),&guest(R)
The xClbraAliasList metadata field is used to specify groups and their permissions for a content item.
Note:
In Content Server, an alias could be used to specify a group of users (which is not the same as a LDAP group). For ACLs, instead of calling the implementation an alias access list, it is called a group access list. However, the metadata field name still uses the term alias.
The following list describes requirements for administrators to specify xClbraAliasList values in scripts:
Each group name is preceded by an 'at' (@) symbol.
Each group's permissions follow the group name in parentheses.
Group names are separated by commas.
Example: xClbraAliasList=@Mktg(RWDA),@Mktg_ext(RW)
The xClbraRoleList metadata field is used to specify enterprise roles and their permissions for a content item.
The following describes requirements for administrators to specify xClbraRoleList values in scripts:
Each role name is preceded by a colon (:) symbol.
Each role's permissions follow the role name in parentheses.
Role names are separated by commas.
Example: xClbraRoleList=:role1(RWDA),:role2(RW)
Access control list permissions determine what type of access a user, group, or enterprise role has to a content item. The following permissions can be granted:
| Permission | Description |
|---|---|
|
Read (R) |
Allowed to view the content item. |
|
Write (W) |
Allowed to view, check in, check out, update, and get a copy of the content item. |
|
Delete (D) |
Allowed to view, check in, check out, update, get a copy, and delete the content item. |
|
Admin (A) |
Allowed to view, check in, check out, update, get a copy, and delete the content item, and check in a content item with another user specified as the Author. |
Note:
Access control list permissions do not apply to users with the Content Server admin role.
To associate access control lists with a content item, you add one or more users, groups, or enterprise roles when checking in or updating a content item. For each user, group, or role you add to an access list, you assign the appropriate permission: Read (R), Write (W), Delete (D), or Admin (A). Access control list permission levels are the same as defined for Content Server security groups and accounts. When users are added to any one of the access lists, the users have the specified permissions to access the content item.
At least one of the following must be true for a user to be granted a particular permission:
The user's name appears in the xClbraUserList metadata field with the appropriate permission.
The user belongs to a group that appears in the xClbraAliasList metadata field with the appropriate permission.
The user is part of an Enterprise role that appears in the xClbraRoleList metadata field with the appropriate permission.
Access control list permissions are cumulative. If you assign Write, you automatically assign Read. If you assign Admin, you automatically assign Read, Write, and Delete.
However, users must also satisfy security criteria for access through the Content Server security group and the account (if Accounts are enabled). If any of these security criteria deny a certain permission, users will not have that permission to the content item.
When a user searches for a content item, all three ACL rights fields are combined as an "OR" condition. That result is combined in an "AND" condition with the result of the Security Group and Account fields. The user conducting the search must have Read permission to the security group, to the account (if accounts are enabled), and to at least one of the three ACL fields to be able to find the content item.
If all the User Access List, Group Access List, and Role Access List fields are empty, then by default permission is granted to all users. If only the User Access List and Group Access List fields are blank (and the RoleEntityACL component is not enabled so there is no Role Access List), permission is granted to all users. This behavior is configured with the AccessListPrivilegesGrantedWhenEmpty variable, which is set to TRUE by default.
If the AccessListPrivilegesGrantedWhenEmpty variable is set to FALSE, then when all access control lists are blank, permission is denied to all users except those with the admin role. For a user without the admin role to be able to check in documents, the user must have an access control list role (such as testrole) with Read/Write (RW) privileges and specify the role when checking in documents.
Note:
If the Content Server instance has been upgraded from release 10g, be aware that empty access control lists will behave differently in Release 11g. Release 10g and earlier had the equivalent configuration of AccessListPrivilegesGrantedWhenEmpty=false. The default for release 11g is AccessListPrivilegesGrantedWhenEmpty=true.