help.axcms.netAxinom Logo
Save Save Chapter Send Feedback

Security Features


The Sophisticated security features in gives it the ability to meet the security requirements of many different customers: from a simple one-user-can-do-everything to the multi-tenant multi-user environment with fine grained authorization controls and auditing. This chapter will cover:

  • Authentication
  • Users, User Profiles and User Groups
  • Authorization: Roles and Rights
  • One level deeper -Checkpoints and Security Matrix
  • Special Considerations for the Live System

Note: The security concepts in the Management System and in the Live System are essentially the same. Because of the two different audiences for MS and LS you can think of them as two instances of the same security model. In the descriptions below, if no other system is mentioned, we are describing the Management System. At the end of the section, you can find special considerations about the Live System.



To use the management system a user must be authenticated. This is done by providing a valid username and password. manages the user credentials in its database.

Alternatively, a user can use Windows Authentication - e.g. together with Active Directory.

Users, User Profiles and User Groups

Every user has a profile in (Even if Windows Authentication is used, there is still a local user profile in The profile contains the fields for typical personal data (names, addresses, contact information, credentials, status, etc.) and can be extended in the project context. Like all other objects, users can be classified, attached to navigation, given tasks and be assigned relations.

Fig. 1 User Profile

Fig. 1 User Profile

Users can be further organized into User Groups. One user can belong to multiple groups and each group can contain multiple users. User groups can be given the same roles and rights as individual users and the group members inherit these permissions.

Authorization: Roles and Rights

Authorization is managed with roles and rights.

Roles are predefined permissions sets which enable the user to perform certain kind of tasks. The standard, included roles are as follows: (these can be extended / customized in a project):

  • User - default role which is given to every user. Very limited role which allows access the main pages in MS.
  • Site Editor - a typical role for a user responsible for the content in a certain responsibility area. Site Editor can create pages and documents. Edit/Publish rights should be given additionally to the Site Edtor role.
  • Site Administrator - this is very powerful role. A Site Administrator is allowed to do virtually anything with the content of the web site. Use it only if there is only one editor or for a team supervisor.
  • System Administrator - this role gives access to the user management
  • Live Administrator - this role gives access to the member management (see Special Considerations for the Live System below)

Rights work differently - they define a simple action which can be performed on some object. For example, a user might have a Publish-right on a certain page. It means, he is allowed to publish this page. Without this right he will not be able to publish this page. The basic rights are: (these can also be customized in a project):

  • Read - read rights allows visibility of the objects. Without a read right the user will not see the object at all - and not even know about its existance. In a typical installation every MS-user has read rights for all content. But some scenarios require more fine tuning, e.g. multi-site applications where each country has its own editors responsible for their own content.
  • Edit - this right enables the user to modify and delete objects.
  • Publish - with this right a user can publish an object to the live system
  • Controller - controller is more of a duty than a right. If a user has Controller rights to an object, his approval is required before the object can be published. It is recommended to give controller rights to user groups rather than a paritcular user and include more than one user into such groups to avoid dead locks. If a group is assigned a controller right to an object it suffices that any of the users gives his approval - such approval is given in the name of the entire group. Be carefull with setting controller rights because it can introduce a level of unnecessary bureaucracy.
  • EditCategory - gives the user the right to edit a category and its subtree, including adding new nodes there.
  • PublishCategory - gives the user the right to publish a category and its subtree
  • ClassifyCategory -  gives the user the right to classify other objects to a category and its subtree. By default any user can classify any object to any category. By manually controlling who is allowed to classify categories, you gain much more control but the amount of administrative work is increased. Be careful to examine the trade offs.

As previously stated, rights always apply to a particular object. It would be too time consuming to set the rights for every combination (user, object), as there can be thousands of objects and hundreds of users. To avoid this, distributes the rights over categories. The Administrator gives a particular user a right to a certain category. This means that the user has this right for every object in this category (and its subtree). A very convenient way to distribute the rights is by using navigation, because every page is usually in some navigation node anyway. However, you can use any category to distribute the rights.

If you need to define special rights for a certain object (which differ from the standard rights inherited over the category hierarchy) you can do so with special rights. There is a reserved subtree "Special Permissions" (its root is configurable). You can create a category under this node, e.g. "Special Rights for XYZ" and assign your page to this node. As soon as an object is assigned to a category under "Special Rights" the standard rights are not applicable anymore. The rights which apply are those given on the node under "Special Rights".

One more exception are so called creator-rights. A newly created object might have no categories attached, which leads to the situation that nobody has any rights to a newly created object. To avoid this dead-end you can define creator rights. "Creator" is a pseudo-category to which you can give the normal rights to any users. These rights apply to all objects created by this user. For example you can give a user edit-right to the node creator. This user will be able to edit all the objects she creates regardless of their categories. Giving a user publish-right on creator enables him to publish any objects she creates, even if she can not publish any objects otherwise.


Fig. 2 Roles and Rights

Fig. 2 Roles and Rights

One level deeper -Checkpoints and Security Matrix

Roles and Rights are not hardcoded into, but rather they are an intermediate concept of a CheckPoint that is used. A CheckPoint is a guard in the code, which protects particular functions. Depending on the user-permissions it either passes through the CheckPoint and can use the function or not (an error occurs). There are 100+ CheckPoints in code.

You can think of the CheckPoints as small locks distributed through and of the Roles/Rights as keys. Every key can open some set of locks. Every lock can be opened by some keys. Every user possesses some subset of keys and therefore can open some particular locks.

Which key opens which lock is defined through a PermissionMatrix. Below you see a section of a PermissionMatrix:

Fig. 3 Permision Matrix

Fig. 3 Permission Matrix

Some CheckPoints only work with Roles because they do not apply to any particular object (e.g. CheckPoints, protecting New-operations or Overview-Pages). Other CheckPoints do apply to particular objects. Such CheckPoints can be used either with Roles or with Rights.

With the permission matrix above you see, that the standard roles and rights are just some reasonable defaults and can be customized in a project. You can create new roles and/or rights or modify existing ones.

For you own extensions you are encouraged to create your own CheckPoints and either assign them to the standard roles/rights or create new roles/rights and assign them there.

Special Considerations for the Live System

In contrast to the management system, in the live system it is not necessary to restrict the access to authenticated users only. Every internet user can see the site. Additionally it is possible to build a restricted area within the web site which does require authentication.

Users requiring authentication in the live system are called members to differentiate them from the users in the management system. So we have users and user groups in the MS and members and member groups in the LS.

Standard user profiles and member profiles are identical. But in a project context, both can be extended. They can be extended independently from one another. There can be different extensions for users and members.

The Standard Active Directory integration is only available in the management system. But for a specific project context (e.g. for an Intranet) active directiory integration is possible also in the LS.

One of the typical uses of the members is the newsletter. A Newsletter is sent to the members from the same category as the one assigned to the newsletter. (In a project you can override this logic if desired.)

The default roles and rights in the LS are much simpler. There is only the Read right which defines if a member can see a certain page/document or not. More rights can be defined in a project.

In the MS all the content is protected by default and a user must be granted rights to be able to access the content. In the LS it is different - by default everything is open and even authentication is not needed. To indicate that an object is protected you classify it to a category under some node which is defined as standard permissions tree. This root is configurable (default is the node with ID=9). If an object is assigned under a standard permissions tree it is considered to be protected. Users have to be authenticated to see the object and then it needs a read right to the protected category. Special permissions trees can be defined for the LS as well.