Chapter 1: Overview

In Sitellite, access control is granted or denied based on a few concepts that work together to form a complete and very flexible privilege system. First, I'll define each concept for you, then I'll discuss Sitellite's default permissions and workflow as an example scenario to help you configure your CMS system to your specific requirements. Rounding out the article, I'll look at integrating access control features into your custom PHP code.

Roles

The first concept in Sitellite's access control system is that of a Role. Users perform certain functions within a CMS that make up their job description within your website. We'll call these functions that a given user performs their Role. However, it's not so straight-forward to define functions or to describe what a user does, so instead we define the Role of a user based on their access to three things: Resources, Access Levels, and Document Statuses.

By limiting or granting access to these three things, a Role becomes a description of a user's function indirectly by defining the range of possible actions users of that Role are able to perform.

Let's look at these three things in more detail.

Resources

A resource in Sitellite can be just about anything. Each collection (ie. content type) and each app or module is a resource. You can also define custom resources for your own apps or even for specific parts of your apps. For example, the Image Manager app defines an additional resource for its delete function so that you can grant access to the Image Manager itself but restrict access to the ability to delete images separately.

Aside: Some apps and collections don't have resources defined for them. To add a resource for a collection, use the name of the collection definition file in inc/app/cms/conf/collections minus the .php suffix. To add a resource for an app, use the folder name of the app in inc/app prefixed with "app_". For example, the "imagechooser" app would be associated with the "app_imagechooser" resource.

Access Levels

Items in the system such as web pages, news stories, even boxes and forms within a given app have an access control value assigned to them. Examples of access levels include "public", "member" for members-only, and "private" among others. Public items are logically accessible to anyone. Members-only items are accessible only once a website member has logged in and has been authenticated by the CMS as a member of the website. Private items are intended for admin-level users only.

Document Statuses

A document can be in one of several states of completion during its lifetime. Defaults within Sitellite include "draft" for incomplete documents, "pending" for documents awaiting editor approval, "approved" for documents that are considered ready for public consumption, and "archived" for documents that should no longer be shown on the site but may still be needed for historical reference by site admins.

By restricting access to these three things, Sitellite is able to describe with a high degree of precision the functions a particular user role can perform. For example, if a user can only access a certain collection (ie. web pages) then their function pertains specifically to web pages. And if they can only access "draft" and "pending" access levels but not "approved" then they are obviously a content creator but not one with sufficient privilege to publish directly to the live website.

Read/Write

Adding further specificity, site administrators are able to grant Read and Write access separately to any of the above on a role-by-role basis. Read access means a user can view but not modify an item, and Write access means they can modify the item as well. This is a familiar concept to Unix system administrators and power users (ie. Linux, Mac OS X), where the filesystem splits permission on every file into Read, Write, and Execute.

Teams/Ownership

There are cases where you may need to grant editorial access for a given user to the website but you'd like to restrict that access to a particular area of the website, such as the Human Resources section of pages so that the editor can manage job postings but can't edit marketing copy for products or services. This is where the concepts of teams and ownership come in.

Teams break users up into groups that perform a series of tasks (their combined roles) on specific parts of a website. The parts (ie. web pages, news stories, etc.) that are available to that team are simply the ones owned by that team. Ownership is defined on an item-by-item basis under the State tab of the edit screen.

The writer who seeks approval for a particular modification to a web page will be looking for this approval from an editor, but specifically from the editor belonging to the same team.

Workflow

This combining of roles into teams creates a sort of natural workflow within the system. Each team's combination of user roles is another workflow cycle, since workflow really just means the series of tasks a group performs and the communication that occurs between them to facilitate the completion of those tasks. In this way, workflow usually centres around the Status property of documents and role definitions. Workflow cycle typically matches the document lifecycle.

Utilizing Sitellite's default workflow settings and setting up custom workflow systems is the topic of a previous tutorial however, so I won't repeat that here again.

Multiple Teams

There are cases where you need a user to be allowed to access items owned by other teams than their own. This is made possible on a per-user basis when adding/editing users, by allowing you to specify both the team they belong to, as well as a list of Read/Write privileges for all teams in the system. This is found under the Access tab of the user add/edit forms.

By default, Sitellite enables new users to Read and Write to all teams, so that team restrictions are something that must be enabled. This default setting helps keep the default privileges useful out-of-the-box for smaller websites that don't require anything beyond the default teams and roles.