Security Groups and Accounts Overview (Part 2)

This is the second of a three-part series on Oracle UCM (Stellent) security.

Accounts

Accounts are an optional second layer of security that you can use inside the Oracle UCM.  To activate accounts, add the following configuration setting to you config.cfg file:

UseAccounts=1

Accounts differ from Security Groups and Roles in a couple of different ways:

• Accounts are applied to documents and to users. 
• Accounts have a hierarchy to them

A document can have only one account.  A user can have access to an unlimited number of accounts.
Accounts tend to be used for very granular levels of security, although the hierarchical nature of accounts allows for wide-spread access across several accounts.

A Sample Hierarchy

Accounts have a natural hierarchy to them.  This allows you to create extremely granular levels of security, but also gives you the ability to grant a wide range of access as needed.  This is fantastic for managers, executives, and administrators who need broad access to some of the content in the system.  It also allows you to fine-tune the distinction between read-access and write-access for several different types of users.

The account hierarchy is typically delineated with a slash (“/”).  The first level of the account tends to be very broad.  The account gets more and more specific as components are added to it.  For example:

Account	Access
dept	All departments
dept/mktg	The marketing account
dept/legal	The legal account
exec	An account for executives
exec/ceo	An account for the CEO
exec/cio	An account for the CIO
exec/coo	An account for the COO

A Common Account Mistake

Because Accounts get more specific and detailed the farther down the tree you go, many users of Oracle UCM create what they think is a highly secure group far down the hierarchy. 

Continuing the example from above, let’s say that you wanted to create a group of secure documents for managers within the marketing department.  Many people try this as an approach:

dept/mktg/managers

This is not a workable solution.  If you were to implement this account, all users who had access to dept/mktg would automatically get the same access to the “Managers Only” account.  This is exactly what you’re trying to avoid!  You can address this problem in a couple of ways:

• Put the “Managers Only” account in another branch.  An account such as managers/mktg would keep these documents safe from people who have access to dept/mktg
• Create a general account for marketing documents.  This will give you two new accounts: dept/mktg/managers and dept/mktg/general
• Use the higher level account for more secure documents, and create a lower level account for documents with more generalized access.  This would entail putting the “Managers Only” content in dept/mktg and the regular marketing documents in a generic sub-account, such as dept/mktg/general.  Managers could have access to the dept/mktg account (and, by order of the hierarchy, dept/mktg/general as well), while regular users of the marketing department would have access into the dept/mktg/general account only.

Usually, the first option is most ideal solution.  (The other two are included just to help you get used to thinking about why account structures work in certain ways.)  The first option helps you set up your structure so that you can use high-level account assignments (such as just dept) to give broad ranges of access to users.

When dealing with accounts, it’s important to think not only about the documents, but also about how you will provide the access to users.  Some common questions to ask yourself as you’re preparing an account hierarchy:

• How are these documents logically grouped together in terms of security?
• Are there common groups of people who need to see the sub-groups inside this hierarchy?
• Do we need to identify some documents for which there is either an expanded or contracted audience that has write access?
• Do we need to identify some users who have expanded or contracted privileges for a subsection of these documents?

Predefined Accounts

System Administrators have the ability to establish Predefined Accounts in the User Admin.  By populating this list, System Administrators make the accounts available via drop-down lists.
Note: Accounts do not have to be defined in this list in order to be used, but doing so makes the management much easier.

Special Accounts

There are two special accounts defined within Oracle UCM:

• #none
• This is for documents with no account.  If a document has a blank or null account field, a user will need access to the #none account to perform actions on this document
• #all
• This is a catch-all account, and grants a user access to any and all accounts in the system.  Use this option with care.

Note: the #none and #all declarations are available only in the User Admin screen.  You assign these accounts to users, but do not assign them to documents.