More about groups, actions, and permissions is defined here: Content Object in Cassandra (Content Tree)
When viewing permissions as sets, the decision on whether a user has permission to do something is easily taken: the set of permissions intersected by the set of groups the user is part of must not be empty.
However, there are cases when a certain action may require multiple authorizations and if all those authorizations are not satisfied, then the user cannot take that action. This is represented by multiple sets of permissions (realms or categories of permissions.)
A good example (which is fairly easy to understand) is page content editing.
You may edit the content of a page if:
A) You have permission to edit the content of a page of that type;
B) The page content uses a filter you are authorized to select;
C) The page was not assigned a tag you don't have the right to access.
In this case, if you do not have all three permissions, the editing of that page is forbidden to you1.
First we'll consider a simple case.
There is one permission: Edit Page.
There are 3 groups: Visitor, Editor, Author.
In this example, only the editor has permission to edit a page. This is represented by the hashing where the two boxes cross each other.
In the simple case, we use an AND operator between the group (editor) and the right (edit page.)
Now, it becomes more complicated when a second right is added. The second right may be cumulative (i.e. if you have one or the other, then you can edit the page) or it can be even more restrictive (i.e. if you don't have both rights, you cannot edit the page.)
In the second figure we see two permissions: Edit Page and Admin Page.
If you have the right to edit a page, then you can proceed.
Here the author has that permission and he can edit the page.
The editor, however, does not have the Edit Page permission, but he has the Admin Page which also means he can do anything he wants with pages including editing. Thus, he can edit the page. (Although the Edit Page could be reserved to the author and the editor can only publish/unpublish pages depending on whether the page is proper for the concerned website.)
In this case, we consider that the permission operator was an OR. The concept is that a certain number of permissions are part of the same category and if any one permission in that category returns TRUE, you have permission to proceed.
Finally, we have the case where more than one permission is applied.
As we can see in the 3rd figure, we need 2 permissions: Edit Page and Filter in order to edit the page.
The Author has the Edit Page right, but not the Filter right. He cannot edit the page.
In this case the permission restrictions are cumulative, or use the AND operator.
Using our Content definitions we can categories all the permissions.
For example, the page permissions form a group such as Page Administration that supplants all the other permissions and gives anyone with that permission the right to edit any page unless another category is applied... for example you may not have the right to publish because you do not have moderator permissions.
The Filter is another example that is defined in a distinct category. The Filtering system is used to prevent some users from using a certain number of HTML tags. You do not want an anonymous user coming to your website and posting a comment which is an IFRAME to some random site with unwanted content! "Better filters", meaning filters that let you enter more HTML code, require increased rights.
Note that this can be represented with mathematical sets, and acted on with the intersection and union operators. Sets in one group are merged with the Union operator. Sets in different groups are reduced using the intersection. If the result is the empty set, then the user does not have permission.
All the roles that users have, and themselves, represent one group (union.)
All the permissions in one group can also be put in the same set (union,) however, when one permission is checked, only that one permission is taken in account (intersection which results in that one permission only.)
When multiple permissions are checked and they all are part of the same group, then all of these permissions are added to the same set (union.)
When multiple permissions are checked but they are not of the same group, they are checked using the intersection.
Example:
In this example, you have a and b which are groups the user is part of, you have w and x which are two permissions of the same category c, you have y and z which are another two permissions of another category d, the user has permission if and only if the formula is true.
In some cases it can be practical to offer an exclusion feature. This means we want to exclude a set of people, a set of roles, a set of another permission category, depending on different parameters (i.e. browser in use.)
The exclusion is applied on the given sets before the unions and intersections. For example, forbidding a user from accessing a page means excluding that user from the set of users before proceeding.
At this point the idea is to create a Content Type called Permission.
One row of content represents one permission (one item in the sets described earlier.) Each permission added to the permission type is categorized. When no category is defined in a permission type, it is considered to be part of the Global group (the default.)
Note that all permissions are typed as an action and as an object of some kind. (i.e. all permissions represent an action taken by a user over an object.)
Permissions are organized in a tree as most of the content is. This means you can generate groups without the need to use complicated tagging. However, tags are also supported so that esoteric groups can be created.
When a set of permissions are checked for a user, we generate the final permission set with:
Implementation Note
Note that if any one union is the empty set, then we can stop the process immediately since the empty set intersection anything else is the empty set.
In most cases, the sets of permissions (3rd line) will resolve as one set of one element. Multiple sets are defined when different permissions are from different categories (i.e. ability to edit content as the author only or edit any content.)
The Content Type can include a description in the body that is translated, etc.
The Core permission system must allow for all the other modules to easily add new permissions.
Snap! Websites
An Open Source CMS System in C++