The Deep, Dark, Secret Origin Of Oracle UCM's Security Model

On a recent blog post about Oracle UCM -- Should Oracle Be On Your Web Content Management Short List? -- CMS Watch analyst Kas Thomas commented that he thought Oracle's security model was a bit spooky. He admitted that this may be because he didn't know enough about it: his concern stemmed from an overly stern warning in Oracle's documentation.

Alan Baer from Oracle soothed his fears and said that the documentation needed a bit of work... The documentation mentioned that changing the security model might cause data loss, which is in no way true. It should say that changing the security model might cause the perception of data loss, when in fact the repository is perfectly fine... the problem is that when you make some kinds of changes to the security model, you'll need to update the security settings of all your users so they can access their content.

Nevertheless, I thought it might be a good idea to explain why Oracle UCM's security model is how it is...

Back in the mid 1990s when UCM was first designed, it had a very basic security model. It was the first web-based content management system, so we were initially happy just to get stuff online! But immediately after that first milestone, the team had to make a tough decision on how to design the security model. We needed to get it right, because we would probably be stuck with it for a long time.

  1. Should it be a clone of other content management systems, which had access-control lists?
  2. Should it be a clone of the unix file permissions, with directory and file based ownership?
  3. Or, should it be something completely different?

As with many things, the dev team went with door number 3...

Unix file permissions were simply not flexible enough to manage documents that were "owned" by multiple people and teams. The directory model was compelling, but we needed something more.

Access Control Lists (ACLs) are certainly powerful and flexible, because you store who (Bob, Joe) gets what rights (read, delete) to which documents. The ACLs are set by the content contributors when they submit content. However, ACLs are horribly slow and impossible to administer. For example, I as an administrator have very little control over how you as a user set up your access control lists. Let's say some kinds of content are so important that I want Bob to always have access, but Joe never gets access. If Bob gets to set the ACLs on check-in, then there's a risk he gives Joe access. It's tough to solve this problem in any real way without a bazillion rules and exceptions that are impossible to maintain or audit.

Instead, the team decided to design their security model with seven primary parts:

  • SECURITY GROUPS are like a classification of a piece of content. Think: restricted, classified, secret, top secret, etc. As Jay mentioned in the comments, these are groups of content items, and not groups of users.
  • ACCOUNTS are like the directory location of where a content item resides in a security hierarchy. Think: HR, R&D, London offices, London HR, etc. These are typically department-oriented, but its also easy to make cross-departmental task-specific accounts for special projects.
  • DOCUMENTS are required to have one and only one security group. Accounts are optional. This information is stored with the metadata of the document (title, author, creation date, etc.) in the database.
  • PERMISSIONS are rules about what kind of access is available to a document. You could have read-access-to-Top-Secret-documents, or delete-access-to-HR-documents. If the document is in an account, then the user's access is the union intersection of account and group permissions. For example, if you had read access to the Top Secret group, and read access to only the HR account, you'd be able to read Top-Secret-HR content. However, you would not see Top-Secret-R&D content.
  • ROLES are collections of security group permissions, so that they are easier to administer. For example, a contributor role would probably have read and write access to certain kinds of documents, whereas the admin role would have total control over all documents. Change the role, and you change the rights of all users with that role.
  • USERS are given roles, which grants them different kinds of access to different kinds of documents. They can also be granted account access.
  • SERVICES are defined with a hard-coded access level. So a "search" service would require "read" access to a document, otherwise it won't be displayed to the user. A "contribution" service would require that the user have "write" access to the specific group and account, otherwise you will get an access denied error.

This kind of security model has many advantages... firstly, it is easy to maintain. Just give a user a collection of roles, and say what department they are in, and then they should have access to all the content needed to do their job. It works very well with how LDAP and Active Directory grant "permissions" to users. That's why it is usually a minimal amount of effort to integrate Oracle UCM with existing identity management solutions.

Secondly, this model scales very well. It is very, very fast to determine if a user has rights to perform a specific action, even if you need to do a security check on thousands of content items. For example, when somebody searches for "documents with 'foo' in the title," all the content server needs to do is append a security clause to the query. For a "guest" user, the query becomes "documents with 'foo' in the title AND in the security group 'Public'." Simple, scalable, and fast.

There are, of course, dozens of ways to enhance this model with add-on components... The optional "Collaboration Server" add-on includes ACLs, along with the obligatory documentation on how ACLs don't scale as well as the standard security model... The optional "Need To Know" component opens up the security a bit to let people to see some parts of a content item, but not all. For example, they could see the title and date of the "Hydrogen Bomb Blueprints" document, but they would not be able to download the document. The "Records Management" component adds a whole bunch of new permissions, such a "create record" and "freeze record." I've written some even weirder customizations before... they aren't much effort, and are very solid.

I asked Sam White if he could do it all over again, would he do it the same? For the most part, he said yes. Although he'd probably change the terminology a bit -- "classification" instead of "role," "directory" instead of "account." In other words, he'd make it follow the LDAP terminology and conventions as closely as possible... so it would be even easier to administer.

I do think it is a testament to the skills of the UCM team that the security model so closely mirrors how LDAP security is organized... considering LDAP was designed over many years by an international team of highly experienced security nerds. I'm also happy when it gets the "thumbs-up" from very smart, very paranoid, federal government agencies...

Beautiful history Bex!

I also had the pleasure of working with the development team and Bex during the mid 90's. One other change that Sam would have made was that of the concept of Security Groups, or more accurately the label. Security Groups are usually referred to as groups of users. In this case, obviously Security Groups refer to a group of content items. If there is anyone out there reading Bex's extremely accurate history above try to force your mind into thinking about Security Groups as groups of documents. I know this seems trivial but I have had the opportunity to train literally 100's of admins on the subject and the common error or roadblock is around this topic. As soon as I could get there head around the concept they were able to get very creative and fit the security model into their operations comfortably.

Jay Kleffman
jkleffman@ironworks.com

thanks for the feedback!

I included your emphasis about how "groups" should be thought of "content groups" and not "people groups." I agree, that is important to emphasize, because "group" in a security context usually means groups of people...

Interesting and informative. I'm not quite so scared now.

I was hoping you'd write this, Bex. Thank you! Very helpful.

Maybe somebody should revise the Oracle® Universal Content Management guide, "Managing Security and User Access," where it says on page 7-4: "If you enable accounts and use them, you cannot disable them without losing data. DO NOT enable accounts unless you are certain that you want to use them." Either the documentation is wrong, or you lose data. It says nothing about the "appearance" of having lost data.

Page 3-3 of the same piece of documentation says: "The number of security groups should be kept at a minimum to provide optimum search performance and user administration performance. If your security model requires more than 50 security classifications, you should enable accounts and use them to control user permissions." I take this to mean that the performance degrades noticeably (or can degrade noticeably) after you scale beyond 50 security classifications. Later, the documentation cites an example where changing a single permission can take 10 seconds. Not to be a pain in the ass, Bex, but how does this support your statement "This model scales very well"?? (I take it back. I am being a pain in the ass.)

One last carp. You say that "ACLs are horribly slow and impossible to administer." For this particular CMS application, that may be true, I don't know. All I know is that ACLs are the de facto industry standard way of doing this sort of thing. When you choose Door No. 3 and invent a nonstandard approach to solving a problem for which the wheel has already been invented, you only end up needlessly confusing and scaring analysts -- and making customers read documentation, something they hate doing.

At any rate, I did learn a lot from your excellent writeup. Thanks for doing it. I feel better now. ;)

Re: Interesting and informative. I'm not quite so scared now.

you cannot disable [accounts] without losing data

Don't know why that's there... the content you checked in is still in the repository, and the metadata is still safe and sound in the database. Users will lose access to these documents, until you either update all your users, or update all of the values for "account" in the database to blank. You can do batch metadata changes with the Archiver tool... which should be done prior to turning off accounts anyway.

I take this to mean that the performance degrades noticeably (or can degrade noticeably) after you scale beyond 50 security classifications.

In general, performance degradation is due to the complexity of the security model, and not the number of groups or accounts. For example, if you have 100 classifications, but most users can only access one or two classifications, you won't see many problems. The "security clause" I mentioned above would be pretty small... However, if every user gets access to 50 classifications in different ways, then you're likely to see performance to degrade a bit because of the increased complexity of the SQL in the security clauses. This can be fixed with some database tuning, however. Some of the admin applets -- like User Admin -- load more slowly depending on the number of security groups, but that's rarely a big deal.

All I know is that ACLs are the de facto industry standard way of doing this sort of thing.

Slow searches are also the de facto industry standard ;-)

ACLs are easy, which is why everybody does it that way. We took a look at how everybody else did it, and knew that they were doing it in a way that would require a ton of hardware in order to function, a ton of maintenance, and a ton of risk. We didn't want to go that route... and what we came up with was pretty close to how LDAP does things. Seems to me like a good gamble that paid off...

I cannot name names, but I encourage you to talk with enterprise architects in industries with serious security concerns -- like financial and government -- to ask them what they think of ACLs in general. As I said, you still can do ACLs with Oracle UCM, but you'll need beefier hardware.

The beauty of complexity

When I first encountered the Content Server's security model back in the late 90's as the Business Analyst for Stellent (then Intranet Solutions) I frequently had to try and find a senior consultant to sit in on customer calls related to security because it could get quite difficult to explain. And when those consultants didn't show up or went screaming from the room because they didn't understand it either I decided to focus on really learning this aspect of the product.

What I discovered was that this arrangement allowed me to make some very complex security models and yet they maintained high performance because the actual queries were simple. Accounts give you the capability to build multiple folder like threads which are parallel, hence I can make one structure for public content, another for departmental public, another for departmental secure and still another for personal. Then in these parallel hierarchical structures I can place simpler Security Groups such as Executive, Manager, Finance, Board notes, etc. to provide another layer of granularity in the accounts structture.

I have used this in projects worldwide for very large and complex organizations. It takes a lot of thought and planning but the end result is usually very comprehensible by the admin based on a few rules that apply to that model. And the performance doesn't degrade. I like what you can do with this stuff but it's not for the faint of heart.

David Johnson
david.johnson@senasystems.com

Great article

Loved the post. Now I want a sequel: "The history of the schema." :)

Confusion over security groups

Firstly, thanks for the great article.

I'm reading through the Oracle UCM Workflow Implementation Guide (link to PDF below).

http://download-west.oracle.com/docs/cd/E10316_01/cs/cs_doc_10/documentation/admin/workflow_guide_10gr3en.pdf

This guide tells me each workflow is associated with a security group. On page 4-11 it shows a screen capture of the "Workflow Admin: Criteria Tab". The screen capture includes a number of "Security Groups" being "HR", "Accounting", "Projects".

After reading your article it appears the example I have referenced in the Oracle UCM Workflow Implementation Guide has mixed up SECURITY GROUPS with ACCOUNTS. What's your take on this?

RE: Confusion over security groups

I don't think there is a mix up of Security Groups and Accounts - as far as I am aware Accounts are just a more fine-grained security classification to your Security Groups e.g. A user may belong to an Account within a Security Group, which gives them lesser privileges but they still belong to that Security Group

RE: Confusion over security groups

This is a classic trade-off in teaching people about things that are related to security -- like workflows -- but are not security. You can either make the sample easy to understand, or you make the security settings realistic.

The more correct example, IMHO, would be to use the classification levels for groups, and the departments for accounts... then use sub-workflows triggered off of the account if needed. However, that's a pretty complex example to dive right into. Alternatively, I'd suggest an example with just the out-of-the-box security groups -- Public, Secure -- and focus on triggering workflows on other kinds of metadata.

RE: Confusion over security groups

I was about to ask the same that was asked, I'm quite confused. We're redesigning the Security Model and I was reading this:
http://rpu.dumgal.gov.uk/xpedio/help/system_admin/security/se_model_r.htm#Accounts%20Based%20Security

I read this blog and I thought I had it figured out, and it made sense but in the link above it makes it totally different.
In the blog it says "Groups are NOT group of users" it should be things like restricted, secret, etc.. which makes sense with what we get out-of-the-box but in this link they use groups like: public, marketing, sales, HR.. etc then accounts being MarketingLevel1, MarketingLevel2, etc..

This is confusing me a lot. Why would they mix Public as a Security Group with Marketing, Sales, HR which are organizational units and they belong to Accounts according to this post (which i liked, thanks a lot).

I don't know anymore how to decide what the security groups in our environment should be anymore.

RE: Confusion over security groups

First to reiterate Security Groups(SG) are groups of content not people.
So you can tag a piece of content in such a way that only those who have permission to that SG can have some type of access to it. But a SG is a descrete thing.
Accounts are a structure and content can be placed in the structure and that heirarchy can determine your access. But remember that content needs a SG but may be granted an Account. Hence a piece of content with SG of Public placed into an Account will have the more restrictive of the union between the two. In the case mentioned it will just be the account permission. But if the SG was secure then the user trying to access it would need both conditions to get access.
Now to go to the example mentioned above. I almost never use Security Groups for organizational secuirty AND I am wary of locking Accounts into the current organizational structure because that changes over time. But if there is a functional structure which parallels the organization then I try to use that. An Example may be that a company has distributed accounting amoung the groups. I might make a Account structure called Finance and put their materials in substructures there. Even though Finance department exists. I might also in HR make a (Public) Account structure for the things that everyone in the organization needs to see. a (Secure) Account structure for different aspects of HR that need to be secret and a blended structure such as /HREmployeeReports/EmpId# with the appropriate HR people having access at the /HREmployeeReports level and individual employees having access to their own /HREmployeeReports/EmpId#. I might also let the HR people put Secure(SG) documents into the /HREmployeeReports/EmpId# account, the employee will not have access to them, yet they stay with the other work in this account.

regarding need to know component

Dear Bex,

You have briefly touched upon the Need to Know component. I have a doubt in that. There is DocDisclosureQuery Applet which is used to build queries on User attributes during checkin and also update on content which gets stored in metadata field. But how to use the query entered during check-in or update. Is it internally used or we should explicitly customize some service or write some filter to make use of that query.

Thanks in advance.
Selvam S

Re: regarding need to know component

I was able to do it. I have posted a small article in my blog.
http://selvam2day.blogspot.com/2010/10/sample-step-by-step-implementation.html

Thanks,
Selvam.

How these security model hold in 11g ?

Bex, I heard about the new release 11g doesn't hold these security model. Is it True ? Partially or completely ? If completely how difficult the new weblogic security model would be ? I kind of overheard without any experience with the new product. Please guide us.

I think the security model is

I think the security model is staying the same on 11g. The thing that changes is that users (and I think roles to) are managed by WLS. Thus you need to create users on the WLS, and UCM has a provider that is obtaining the users from WLS (like an existing LDAP provider).

Only update your own documents

Hi all,
I'm dealing with the scenario of setting up Knowledge Base realized with UCM. The requirement is that all employees are able to check in documents, and later on update them if they want to. However, they should not able to update documents of which they are not the author. If I set up a security group KnowledgeDoc and an employee role with RW permissions on that group, all employees can edit all the documents in the security group. Would the only way to do this to create an account with RW for everyone and assign the account to all documents that a user checks in?

Regards, Stijn

Help with UCM Security

I was reading an entry you made about Oracle’s security model on UCM. We are trying to build a portal that has a security model where we need to be able to take a piece of content and have it seen by multiple customers. To this extent, we need a many to many relationship between content and groups of users.

I was wondering if you had any ideas on how to achieve this. As an example, it seems that content has a single relationship with security group and account. If this is the case it means we need to have a security group or account for every piece of content that we have. Then map roles into that layer. That way we have a login being able to view content they have rights to see.

The problem I have with this is
1 – it seems to be a costly endeavor to need to replicate each piece of content with a security group and account.
2 – There would be a lot of management to keep this in synch.
3 – as the content count grows into the millions, I am concerned this model will fall on its face and slows down.

Any experience or ideas, would be greatly appreciated.

What will happen in this scenario?

Q: Acme_Admin role has Read, Write, Delete permission to all content in the Acme Security Group in UCM. A user is assigned the Acme_Admin role, and is also assigned Read, Write, Delete and Admin permission to the Acme-Pub account in Active Directory. Therefore, the user has Read, Write, Delete and Admin permission to a content item that is in the Acme Security Group and the Acme-Pub account in Active Directory. True or False?

False. Your effective

False. Your effective permissions are the intersection of the account and security group, not the union,

Acme-Pub(RWDA) + Acme Security Group(RWD) = effective rights of (RWD) to said documents.

Permisions correction?

Bex,

Great post on UCM security, btw! You may want to update your explanation of Permissions on your initial post, as it states "If the document is in an account, then the user's access is the union of account and group permissions.". I think you meant to say "If the document is in an account, then the user's access is the intersection of account and group permissions.".

Cheers,

Chad :^)

d'oh!

Yes, wrong word there... the prose is correct, but I used the wrong label. It's updated now.

Read only access after workflow

Hi Bex and thanks for all...
I have a scenario where all users can checkin a document into a workflow, but after the workflow has ended they should have only read access...
What would be the most appropriate way? I tried to change the Security group at the end of the workflow (to a read-only SG) but i am not allowed to change the SG as long as the document is in the workflow.
Would it be the solution to create Read-only accounts? (for instance '01' and 'R01'). But how can i change the account at the end of the workflow?

thanks in advance....
Sakis

Recent comments