CMS Security Model

Actions: Verbs

Every content object type defines a collection of possible actions; each of these actions corresponds to a potential permission.

For simple objects, like this document, the basic actions would be:

• Read
• Add (Comment) -- allows new material to be added to the document, but existing material cannot be changed.
• Edit

In addition, there are several actions pertaining to metadata; content-related metadata would probably fall into the Read or Edit permissions, while security- and workflow- related metadata would have specific actions. In particular, each possible workflow transition would be an action, such as:

• Publish
• Unpublish

In some security models, Folderish objects (that is, collections) have two types of Read permission, one which produces a content listing, and the other of which only permits traversing the folder to a named child object. This is an unnecessary complication: the content listing should only show content for which the user has some permission.

More complex objects, such as discussion lists, might have specific actions, like *Add new topic". The security model must support this flexibility, but its use should be discouraged unless there is a demonstratable need.

Actors: Subjects

The fundamental principle is that every Actor has a unique identity which is authenticated by a single identity repository. Information about the actor (name, favorite color :), e-mail address, relationships with other actors) can be acquired from this repository ''or'' it can be kept in a particular application. In general, security-related information should be stored in a shared authorisation repository, non-confidential personal information should be stored in the identity repository, and application-specific information can be stored in some application database. (This latter option should be discouraged, though.) LDAP databases should be used whenever possible. Schema must be documented.

Security Domains

Conceptually, the association between Actors and Actions on Objects is controlled by an Access Control List. However, it is impossible to maintain ACLs as a matrix betwen a huge number of actors and a huge number of objects. Consequently, both actors and objects must be grouped (and, indeed, it may be necessary to group Actions as well for complex objects.)

For authorisation purposes, objects are grouped into Security Domains. Each object belongs to exactly one security domain (for now), although security domains can be defined in a hierarchical structure with upward inheritance. Deep hierarchies should be avoided.

Security domains have only a casual relationship with site structure or even object containment relationships. A given object may appear on several sites, and may appear to be in several containers. However, an object's access rules must not be affected by the route used to acquire an object. On the other hand, it may be necessary to define rules which prevent objects with particular security domains from being placed into particular sites or containers. Additionally, the container in which an object is initially created may define the new objects default security domain.

The object's security domain is essentially a metadata property, but it may be a computed property. In particular, workflow transitions should change an object's security domain, rather than trying to write access control rules which use workflow state as a parameter. So, for example, the security domain of an object might be computed by appending workflow state ("draft", "review", "published") to a base security domain ("intranet/policy_team/").

Security domains can themselves be objects, and thus controlled by the normal access control model. In other words, assigning an object to a security domain may be controlled by some defined Action on the Security Domain object.

The security domain structure must be an acyclic directed graph. Trees should be preferred where possible, but acyclic graphs are used in preference to regular expression matching on the domain string, which is far too error-prone and too difficult to audit.

Specific Metadata

The project security model requires that each document be marked as "public", "internal" or "restricted". This metadata must be set at document creation, and can only be changed by someone authorised to do so (at least, it could only be changed in the direction of public by someone authorised to do so).

Rather than complicating the access model, I would suggest that this metadata be implemented in workflow; an object marked "internal" could not be published to a security domain marked "public" and an object marked "restricted" could only be published to a security domain with some access control. An auditing tool could also be periodically run to verify that the constraint continues to hold.