New security configuration flag in UCM PS3

While the recent Patch Set 3 (PS3) release was mostly focused on bug fixes and such, a new configuration flag was added for security.

In 10gR3 and prior versions, UCM had a component called Collaboration Manager which allowed for project folders to be created and groups of users assigned as members to collaborate on documents. With this component came access control lists (ACL) for content and folders. Users could assign specific security rights on each and every document and folder within a project. And it was possible to enable these ACL's without having the Collaboration Manager component enabled. But it took some special instructions (see technote# 603148.1) and added some extraneous pieces still related to Collaboration Manager.

When 11g came out, Collaboration Manager was no longer available. But the configuration settings to turn on ACLs were still there. Well, in PS3 they've been cleaned up a bit and a new configuration flag has been added to simply turn on the ACL fields and none of the other collaboration bits.

To enable ACLs:


Along with this configuration flag to turn ACLs on, you also need to define which Security Groups will honor the ACL fields. If an ACL is applied to a content item with a Security Group outside this list, it will be ignored.


Save the settings and restart the instance. Upon restart, two new metadata fields will be created: xClbraUserList, xClbraAliasList. If you are using OracleTextSearch as the search indexer, be sure to run a Fast Rebuild on the collection.

On the Check In, Search, and Update pages, values are added by simply typing in the value and getting a type-ahead list of possible values.

User Typeahead

Select the value, click Add and then set the level of access (Read, Write, Delete, or Admin). If all of the fields are blank, then it simply falls back to just Security Group and Account access.

ACL Metadata Values
As for how they are stored in the metadata fields, each entry starts with it's identifier: ampersand (&) symbol for users, "at" (@) symbol for groups, and colon (:) for roles. Following that is the entity name. And at the end is the level of access in paranthesis. e.g. (RWDA). And each entry is separated by a comma.

So if you were populating values through batch loader or an external source, the values would be defined this way.

Detailed information on Access Control Lists can be found in the Oracle Fusion Middleware System Administrator's Guide for Oracle Content Server.


Hi Kyle, Great post, great feature. What happens when UCM is using Active Directory or external LDAP providers? Will the complete user list appear in the type ahead?

Posted by Tal on February 27, 2011 at 11:29 PM CST #

Hey Tal, Only when those users have logged into UCM at least one time will they appear in the list. When a user logs in the first time, a local database entry is made for that user. It's that table that is used for the type-ahead list. In some cases, customers "prime" that database table by importing their usernames in so that a user doesn't necessarily need to log in for it to be there. Thanks, -Kyle

Posted by kyle.hatlestad on March 22, 2011 at 11:03 PM CDT #

Great post, Kyle. With respect to Tal's post, I was able to get the Users enabled by adding the users to the USERS table (I'm using AD). However, I can't get the Group ACL to work in the type ahead.

Posted by Mark Zawadzki on April 05, 2011 at 05:16 AM CDT #

Figured out groups on my own - it's a case of bad labeling as these are really aliases NOT groups.

Posted by Mark Zawadzki on April 05, 2011 at 05:24 AM CDT #

What's annoying is the fact that if I define a folder structure and give permisions to only a limited number of users for this structure , other users still can see the entire structure and also the inside docs. I think that normally the structure should be hidden to the users that are not in the ACL.

Posted by guest on June 05, 2011 at 09:13 PM CDT #

If users are able to see either the folders or documents inside those folders and are not part of the ACL list, then something isn't configured correctly. Remember that the Security Group applied to that folder or document must also be defined in the SpecialAuthGroups configuration flag. That is most often the thing missed. Thanks, -Kyle

Posted by Kyle Hatlestad on June 08, 2011 at 02:40 AM CDT #

Because everybody needs read write access on the special auth group, I think the (folder) structure is visible to the users, but of course not the content.

Posted by Murty on July 11, 2012 at 02:42 PM CDT #

Hi Kyle,

Say SpecialAuthGroups=Legal is configured, we need to give the users RW on this group, if you create any folder with this security group - users will see the structure of folders. Is not it? How can we hide the structure of folders - of course, they can not read the contents of folders, but can see all folders.

Am I missing, anything here? For content it is fine, but folders

I am assuming the security will check in this order first security group, account and then acl?


Posted by Murty on July 16, 2012 at 12:51 PM CDT #

Thanks Kyle for posting this. This seems to mimic most of the old Collaboration Server functionality when combined with the 11g Folders Component.


Posted by Brent Seaman on August 28, 2012 at 02:49 PM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Kyle Hatlestad is a Solution Architect in the WebCenter Architecture group (A-Team) who works with WebCenter Content and other products in the WebCenter & Fusion Middleware portfolios. The WebCenter A-Team blog can be found at: ateam_webcenter/


« July 2016