Documentation

1. UML class diagrams
- 1.1. User management class model (MUM)
- 1.2. CMS class model
2. Authorisation

1. UML class diagrams

User management class model (MUM)

The main entities of the user management are:

Zone
Group
User
Company
Dashboard

Download MUM class modell

TOP

CMS class model

The main entities of the content management system are:

Article
Article Category
Image
Podcast
Video
Advertise
Tag

Download CMS class modell

TOP

2. Authorisation

2.1. Security concept based on Talos

The basic authorization concept of Tiny Marbles uses 'Zone', 'Group' and 'User'. The user inherits the permissions of the group, the group inherits the permissions of the zone. The groups can be organized as a group tree, the user can be assigned to a group node and inherits the permissions from the group nodes. The users inherits automatically all permissions of the parent group nodes as well. Therefore it is enough to grant permissions to the root group if all users of this particular tree should have the same permissions. In your code you simply pass the user, group and zone information of the signed in user to Talos, and ask if actions for the user are allowed. Actions could be for example: 'create an article', or 'delete a user' or 'upload an image'.

You are able to grant or revoke permissions to the entities Zone, Group or User
In case you would like to check if 'create article of the type HTML is allowed' for a signed in user, you would write the following code using Talos: talos.withSubjectOr(‘Zone’,‘Group01’,‘Group02’,‘User’).andCategory(‘Article HTML’).isAllowed(‘Create Article HTML’);
The permissions of ‘Zone’, ‘Group01’, ‘Group02’, ‘User’ are related with ‘OR’: if at least one of these items has permission ‘create’ on ‘articles’ the return value is ‘true’.
With that behaviour the user management provides inheritance. For example: we grant ‘create’ for the category ‘articles’ to the whole zone. Each member of the zone is allowed to ‘create’ new ‘articles’, even if the user himself doesn’t have the permission.

Zone concept

The 'Zone' is the basic security entity in Tiny Marbles. Mostly one zone for a project is enough, but Tiny Marbles provides a way to work with more than one zone. Here some basic rules of the zone concept for a better understanding:

'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 Tiny Marbles 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’.

In the following screen below you can see how the permission mapping is done in Tiny Marbles: In this example we set for the category 'Article HTML' the simple permission "Create Article HTML' for the user 'jane' and the group 'secretary'.

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.

Permission Groups

Permission 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.

The 'superadmin'

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.