When you are tasked to implement an Enterprise Content Management solution using Oracle WebCenter Content (WCC), one of the first item to address is to plan your content security. It is important to implement this before you start checking-in or importing documents in to WCC to avoid any future rework. This post describes the best practices around implementing an enterprise scalable security model involving Security Groups, Roles and Accounts in WCC.

WCC Security Model is one of the most commonly misunderstood topic. An improper implementation can lead to several constraints in the future and also cause performance issues, especially in a system that is built to become an Enterprise Content Management system. So it is important for both business leaders and technology leaders to understand the concepts and plan for a model that will best suit the needs of their organization.

Before jumping into WCC security concepts, I would like to describe a  situation and request you to solve it.

Let us assume that you are made in-charge of managing all valuable and invaluable assets of your organization. These assets include several artifacts – some that public can view, while some that only your employees can view/touch/manipulate/destroy and some more assets only selected employees should be able to view/touch/manipulate/destroy etc. The tools you are provided are the following:

1. Buildings
2. Security systems to lock the building and provision Access Badges
3. Locks and Keys to lock individual floors/rooms.

With this type of setup and tools, it becomes quite obvious how the assets can be categorized and public users and employees can be allowed to access them. One thing I would like you to ponder is the number of Buildings you will construct, types of Access Badges you will design and number of Lock and Keys you will plan to use. I am guessing that there will be fewer buildings, few types of access badges and several lock and keys.

Now let us jump into the world of WCC.

In Oracle WebCenter Content Security Groups, Roles and Accounts are three elements that allow you to meet any complex content security needs. Now let me explain about these three elements.

  1. Security Group: Security Groups are entities defined in WCC that can be applied to every piece of content stored in WCC. You can create any number of security groups but best practice is to keep them at a least possible number. Security Groups should group/classify content by their security at an organization level. In an Enterprise System, rather than using them to group documents by department or any subset, it is best to use them to classify the security of the document at an organizational level.
  2. Role: Roles are entities defined in WCC that can be granted to users who access the system. Roles define the level of access a user has on a particular Security Group.
  3. Account: Accounts are applied to documents and granted to users and can be defined in LDAP server that is integrated with WCC. Accounts allow you to restrict access to documents at a department level or any other sub group level.

As you have noticed Security Groups and Roles are defined in WCC, while Accounts can come from external LDAP. In essence you should define Security Groups and Roles such that they will meet all future needs of your organization. This way when new departments/document groups are imported into WCC you will not be required to make any changes in WCC. In order to implement a scalable enterprise security and access permissions, you need to thoroughly understand the purpose and uses of these three elements. A proper implementation will ensure that your systems performance will be optimal when large volume of content has been imported in to your system.

To better understand Security Group, Role and Account – A comparable analogy is to consider Security Group as similar to Buildings of your organization. Roles are similar to Access Badge to the buildings (with a single badge providing access to a single building). Accounts are similar to lock and key. Some assets inside the building might be secured with a lock. Apart from having a badge to enter the building a user should also have the key to access a locked asset.

Now for example, you can house all internal documents of your organization in one Security Group and all Public documents in another Security Group. One thing you should avoid is building separate buildings (Security Group) for each departments in your organization. Using this high-level classification, You can then secure documents that are sensitive in nature using locks (Accounts applied to documents) and providing the keys (Accounts granted to users) to appropriate users.

Following can be your Security Groups for an Enterprise Content Management system that will host both Corporate/Internal and Public content:

Security Groups:

  1. Public – documents that are suitable for world to view. Ex: Press Release or Public website content
  2. Corporate – documents that are suitable for all employees to view, but not suitable to general public. Ex: Corporate Announcement or Intranet Web Content.

Note: You can create a third group “Protected” if you have sensitive/confidential documents that only certain users/group of users should have access. The out of the box “Secure” group is used to secure system files, but you can re-purpose the same for Protected documents as-well. Further, Corporate Departmental content can be protected (If desired) using Accounts.

Roles:

For each of the Security Group you can define two roles as below:

  1. PublicConsumer (This is same as the out of the box role“guest”)
  2. PublicAuthor
  3. CorporateConsumer
  4. CorporateAuthor

The following can be the permissions of these Roles on your defined Security Groups

Permissions

Accounts:

Accounts can be established based on your organizations structure and hierarchy. Your top level accounts can be:(Replace OTS with an acronym that represents your organization)

  • OTS-Pub (Create this to divide your public content)
  • OTS-Corp

You can then further create accounts specific to departments or sub groups:

  • OTS-Corp-FIN
  • OTS-Corp-MAR
  • OTS-Corp-HR

A feature that is useful while using Accounts is the ability to support a hierarchy by using “-” as the separator. For example a user who has been granted OTS-Corp automatically has access to OTS-Corp-HR. This feature allows you to add content in the future that existing users gain access automatically.

LDAP Groups:

WCC translates all LDAP groups of logged in user to Rolesand Accounts. LDAP groups that start with “@” areconverted into Accounts. The following can be your LDAPgroups to support the Roles and Accounts described above:

  1. PublicConsumer
  2. PublicAuthor
  3. CorporateConsumer
  4. CorporateAuthor
  5. @OTS-Pub
  6. @OTS-Corp
  7. @OTS-Corp-FIN
  8. @OTS-Corp-MAR
  9. @OTS-Corp-HR

Further, by default Accounts as described above provides Read, Write and Delete access. You can restrict access by using the following convention:

  • @OTS-Corp-HR_R (Read only)
  • @OTS-Corp-HR_RW (Read and Write only)

Permissions granted by Accounts takes precedence over permissions granted by Roles. So a user with CorporateAuthor role can be prevented from making changes to a document by provisioning the user with a Read Only Account.

Few other topics you may need to be aware of:

  • Maximum number of allowed Security Group is 50
  • Search performance is directly impacted by number of Security Groups a user has access to as the search query appends the Security Group in the WHERE clause
  • WCC Credential Maps allow you to map LDAP groups to Roles/Accounts from within WCC
  • Most LDAP servers have a limit of 80 characters for group name

Hope this was a good primer to understanding the use of Security Group, Role and Account in WCC. Your implementation should depend on your Content Management System requirements. A proper planning and implementation will allow you to build your WCC environment to support a highly scalable enterprise content management system.