Zone concept of the user management system
The 'Zone' is the basic security entity in Tiny Marbles CMS. Sometimes one zone for a project is enough, but Tiny Marbles CMS provides a way to work with more than one zone. Here some basic rules of the zone concept for a better understanding. In this chapter the documentation uses directly the libraries MUM (User management) and CMS (Content management). The website manager of Tiny Marbles CMS uses both libraries, and uses the term 'WSM' instead of 'MUM'.
- 'MUM', the default zone, is the home zone of the administrator
- It is possible to create new zones, but each new zone is a member of the default zone.
- New zones are helpul to maintain several domains with separate design and completey different content
- A zone acts always as a container to the groups, users and the related permissions inside the zone
- Each object or category inside a new zone is related to its own zone and cannot be seen from other new created zones, apart from the default zone 'MUM'.
- When a new zone is created, the system creates automatically all new needed categories in Talos related to the new zone, for instance: 'liveticker:Image', 'charite:Article HTML', ...
In the drawing above you see an example with three zones: the default zone 'MUM', and two other zones: 'liveticker' and 'charite'. We have the users 'Andy', 'Mary' and 'Jane' who are all member of different zones with different permissions. Check out the following situations to understand how the authorization system in the user management is working.
- 'Andy' is allowed to see (='View User') all MUM users, and is allowed to read (='Preview Article HTML') all articles in the zone: 'liveticker''
- Mary' can read all articles of the type 'HTML', because she inherits the permission 'Preview Article HTML' on 'liveticker:Article HTML' from the zone:liveticker, where she is a member.
- 'Mary' can list all articles of the type 'HTML', because she inherits the permission 'List Article HTML' on 'liveticker:Article HTML' from the parent group
- 'Mary' can create new articles of the type 'HTML', because of her own permission.
- Mary is not allowed to see users in the MUM zone or articles in the zone 'charite''Jane' can read and list all article of the type 'HTML' (permision form her group 'secretary' and the zone:charite). She also has permission to list and view articles of the type 'News', which she inherits from the parent group 'staff'. She is onot allowed to create new articles.
- 'Jane' is not allowed to see users in the MUM zone or articles in the zone 'liveticker'
- It is not possible to grant permission for 'Mary' or 'Jane' on objects or categories outside their own zone
- It is possible to grant 'Andy' permission on Talos categories for all zones in the system, for instance: 'Preview Article HTML' on 'liveticker:Article HTML'.
Permission mapping and permission groups
In the following screen below you can see how the permission mapping is done in the user management system and the CMS: In this example we check for the category 'Article News' the simple permissions for the group 'Editor':
Article types and single articles
To control the single article, the system automatically adds the article to the correct Talos category of the according article type when the article is created, for example: 'Article HTML'. In case you would like to grant permissions on a specific article itself without using Talos categories, you need the Talos objects. With the help of Talos object you can grant or revoke for an article with a specific ID. Talos objects are not part of the basic Tiny Marbles release, but the principle works very similar to the Talos categories. For more information about Talos objects and Talos categories take a look in the Talos documentation.
Groups are lists of single permissions. For example, the new Permission Groups 'editor' is a combination of set of Simple Permissions like 'Create Article', 'List Article', 'Modify Article' and 'Delete Article'. Now it is enough to grant subjects (zone, groups, users ...) the permission 'editor' instead of granting each single permission. It is possible to create new Permission Groups at runtime, but it is not possible to create new Single Permissions at runtime. New Permission Groups which are created at runtime are not used in the existing business logic of MUM. They are used to simplify the work for an administrator who has to manage permissions.
After deployment MUM provides the default zone 'MUM' and a default user, the 'superadmin'. The username of the 'superadmin' is called 'admin' with the password 'admin' and is created with all permissions at installation time. It is possible to rename the username of the 'superadmin' and change the default name 'admin' to another name of your choice. The 'superadmin' is the default user of the default zone 'MUM', he has all permissions and can do all in all zones. The 'superadmin' cannot be deleted, and it is not possible to change (grant/revoke) the permissions for him. First thing a 'superadmin' probably will do in a real project: create a new group and call it 'Zone admin' for the default zone and grant permissions.