Wednesday, April 1, 2009

Security Groups and Accounts Overview

Oracle (Formerly Stellent) provides several ways to restrict access to documents, and the terminology and structures can get somewhat confusing at times.  I’ve written this blog entry to help clarify some of these terms and help people get a better understanding of the concepts and terms involved with Oracle UCM security.

This blog entry is split into several sections  Today we’ll cover Security Groups and Roles, next up will be Accounts, and that will be followed by a couple of examples of how they all work together.

Security Groups

A Security Group is a categorization of security that is linked directly to a piece of content.  Documents have Security Groups; users do not.  I like to think of a Security Group as a broad section of security.  Every document must belong to one and only one Security Group.  By default, Oracle provides two Security Groups: Public and Secure.  Many people expand these to larger categories of broad security.  Some typical values are:

  • Use-based Security Groups:
    • Intranet/ Extranet/ Public
    • Internal/ External/ Officer
  • Department-based Security Groups
    • Legal/ HR/ Marketing
  • Location-based Security Groups
    • SanFrancisco/ Boston/ London
You can have as many Security Groups as you like in the system, but people tend to keep this number down to a minimum.  Remember, Security Groups tend to represent broad categorizations of security, so try to keep this number under control.  If you need more discrete control over document security, I recommend looking at Accounts.

Roles

A Role is a definition of access that a user has to specific Security Groups.  Each Role references one or many Security Groups.*  For example, the following roles may be defined in your system:

Role Access
Intranet Contributor Intranet (RW)
Reader Legal (R)
HR (R)
Marketing (R)
London Admin London (RWDA)
A Role is associated with one or many users, and a user can have many Roles. 

* Note: a Role can be used to define access to administrative applets as well; it is entirely possible to have a Role that does not address a Security Group.

No comments:

Post a Comment