Azon Media

Security Model

The security model is role-based with roles hierarchy and permissions for every object (operation, page, file) in the system. The possible actions (and hence the possible permissions) that a user can perform with the objects is not fixed - it can be expanded in future to include more. Each object has its own set of actions/permissions that are meaningful for its type. For example an operation has read, execute, chmod and chown while a page has read, write, rename, delete, chmod, chown (more on these later). A permission is the combination of role-action-object. In fact in Guzaba the subjects (the users) are represented by their own role internally. This way each subject has its own primary and unique role which can contain other roles (in a three like or more precisely in an oriented acyclic graph structure). A role that contains other roles automatically receives all their permissions as delegated to it (thus containing the roles). The primary role of a subject can not be contained in another role (which is meaningless - a subject to contain another subject) - instead it can contain many ordinary roles. Each object has  an owner - a role. This can be an ordinary role or a primary role for a specific subject - in this case it is said that the subject owns the object or in the former - that the role owns the object. The owner of has always the full set of permissions for the object (i.e. can perform any action that is supported and meaningful for this object; different object may have different set of support actions!) and these permissions are irrevocable. They are granted automatically when an object is created and by default no other subject/role besides the owner has any permissions. Then the subject (user) can grant some permissions (chmod) to one or more of the roles of which he is member, or even change the ownership (chown) and grant it to another role or subject. Here comes an important limitation introduced in order to provide isolation and separation of the duties and the possible document flow. A permission or ownership can be granted by the owner only to a role that he is member of or another subject that is member of one of the roles of the owner. This way is possible to completely separate two departments by placing the subjects in two completely separate roles hierarchies with only one intersection - one role which members can pass documents between the two departments.

There are two "layers" of permission checks when a specific operation is executed over a specific object. Lets say a subject wants to read a specific page. First the system will check does the subject has permission to execute the operation "reading a page" and then will check does he have permission to execute the "read" action over the specific requested page. This allows both fine-grained permission tuning (on a per object basis) and a easy denial of a specific action by revoking the "execute" permission over the operation that implements the specific action (in the example "read" action).

The security framework also supports privileges. The privileges provide the user/role with the privilege to perform a specific action over all objects in the system no matter of the permissions. Thus the privilege "read" acts like a granted "read" permission on all objects in the system. The privileges can be used to create "privileged users" (like in the operating systems), or even a super user (like "root" in UNIX) when all privileges are granted. The privileges are not required in order the CMS to be used - it is perfectly usable without them, but they provide extra options regarding the administration.

Revisions

Many objects in Guzaba CMS are versioned. Each version is a separate object/record on its own with its own set of permissions and owner. Some of the properties of the versioned objects are the same which gives the possibility to refer to them as a whole as one (versioned) object. Each change in their content results in creating a new revision of this object. The revision is in fact an independent object of itself with its own owner and permissions. Thus the different revisions can have different permissions and owners. In this sense the versioned objects are more like a union of several objects with common handle and are changed all at the time when specific actions are performed on the object. For example when renaming or moving the object all the revisions are moved or renamed (the "rename" permission is not implemented yet - at the moment renaming requires "write" permission instead of "rename"!). When a new revision is created it behaves like an ordinary object - it is owned by the subject that created it (even if it is based on an earlier revision from a different owner) and has the default permissions for the owner as described above. When a subjects accesses a versioned object without specifying which  revision is requested the last accessiblee ("read"-able)  by this subject revision will be provided. This way having different permissions for the different revisions permits to have drafts of the documents (not published/accessible yet for all roles). When a new revision is created (or a sequence of revisions) they are not accessible by all, and when according the organization's internal policies a specific revision is approved it is marked as "read"-able for the required role. This way in a more complex environment is possible to have multilevel drafts - a different draft revision to be accessible for different roles.

Image Galleries

To each object in the system one or more image galleries can be attached. The image galleries do not have own permissions, instead they use these of the object to which they are attached. The system supports versioned galleries in a similar way of the versioned objects - each time a change in the gallery is made (added/removed/reordered pictures) a new version is created.

Handling objects

A general policy in Guzaba CMS (unlike UNIX) is that is a subject/role has no read access to an object the object will not be shown at all (for example in some group listings). When deleting, moving or renaming a group that contains sub-elements (like an ordinary tree structure of files & folders) the permissions of the sub-elements are also checked. In case for one of the sub-elements is not even readable by the subject an error message will be shown which does not reveal the name of the object, but only its ID. This is required in order to follow the stated policy that if a subject has no permission to read an object there should be no way to even obtain its name (no covert way for obtaining information!). In this case when an action can not be performed because of a lack of permissions the subject should contact another subject who has more permissions in order to resolve the situation.