Skip Headers
Oracle® Fusion Middleware Administering Oracle WebCenter Content
11g Release 1 (11.1.1)

Part Number E26692-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

21 Managing Access Control List Security

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:

21.1 Introduction to Access Control List Security

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:

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 11.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 C.

21.2 Configuring Access Control List Security

To set up access control lists (ACLs), configure the following items in Content Server:

21.3 Metadata Fields

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.

21.3.1 xClbraUserList Metadata Field

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)

21.3.2 xClbraAliasList Metadata Field

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)

21.3.3 xClbraRoleList Metadata Field

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)

21.4 Access Control List Permissions

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:

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.

21.4.1 Empty Access Control List Fields

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.