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.
- Should it be a clone of other content management systems, which had access-control lists?
- Should it be a clone of the unix file permissions, with directory and file based ownership?
- 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
unionintersection 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...