help.axcms.netAxinom Logo
Save Save Chapter Send Feedback

Protecting Live System applications using AxCMS.net security model.

 

Step-by-step tutorial on implementing provided concepts in your application.
Main concepts of AxCMS.net security model were described in previous chapters (see Security). Current topic describes how to use them in practice.
As an example some abstract forum board will be taken, as for many users well-known and understood real life application. The process of implementing typical security design will be explained step-by-step in contrast to AxCMS.net framework/system basics.

The example

So our example application has a root – main board; let’s call it ‘forum’. Forum contains ‘threads’. Each thread consists of subjects (or topics). Discussions are performed under each subject. The following graph represents our example forum:

Forum can be protected by both – roles and rights. The difference is that roles permit user some system-wide actions, but rights allow access to particular objects. It could be not so comfortable to use only roles (e.g. administrator/moderator roles) for restricting illegal actions in forum. Rights are a little bit more advanced, allowing different management of system entities to every single user.
Actually, there is not so much difference between roles and rights on implementation level. The main ways of usage are almost identical. Below, the process of extending rights for the Live System will be described. In case of principal differences all of them will be explained.

So in current tutorial the use of AxCMS.net security model will be described in perspective of using rights to protect content. These are, for example: read, write, upload and administrate. All these rights will be assigned to ‘threads’. It means that all existing messages in some concrete thread can be read only if appropriate user has the right read, new messages posted – if he has the right write; media content can be attached to the newly created posts having upload right, and an administrator can also delete messages.
It is also sometimes important if defined rights are organized somehow hierarchically. Of course, logically, if user has the upload right in the thread, he also can read and post new messages under it. An administrator of the thread has the full access to the content etc.

AxCMS.net allows to achieve functionality described above very quickly and easily. There are no any prerequisites, and the system also does not need any extension or additional configuration.  The implementation process of any security design is still quite simple. Taken example problem is not the hardest situation which can be solved by AxCMS.net, but one that helps to demonstrate the main idea of security model provided by the framework/system.


Workflow (part 1)

The basic concept of AxCMS.net security points at the ‘checkpoint’ definition. Checkpoint is a guard in code which helps to protect particular system’s blocks. In AxCMS.net perspective checkpoint initially is a category.
Both roles and rights are also category entities. In the CategoryTree they are under the root node ‘Roles’ (ID = 10 for MS or ID = 27 for LS) or ‘Rights’ (ID = 20 for MS or ID = 26 for LS) accordingly.
Checkpoint interconnects all permission categories needed to pass through it. It is classified with all these categories from which a user should have at least one to get access to the object/function in the system. One checkpoint can be classified by many roles/rights; one role/right can classify many checkpoints.
There is also one important note for the good system’s architecture design: checkpoints do not have to be logically dependent on roles or rights. It means that they are similar to ‘definitions of access’. They are created and used with an idea of specifying what actually has to be protected, but not what roles/rights are needed. More specifically:

  • In described above forum, threads have to be protected from illegal access so that only authorized users may read, create, attach media to or delete messages, thus the following checkpoints can be added to the system: ForumReadAccess, ForumWriteAccess, ForumUploadAccess and ForumDeleteAccess.
  • There are four rights suggested: read, write, upload and administrate. But if there is a need to add some new role or right (for example, ‘moderate’) it is not always necessary to add one more checkpoint. Moderate is, for example, a role/right to only read and delete messages. So both ForumReadAccess and ForumDeleteAccess checkpoints have to be classified by that permission category.

So, with the following SQL-script both right and checkpoint categories defined before can be added to the database:

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (271, 100, NULL, 1000, 'ForumReadAccess', 4, 1002400, getdate(), 1,
getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (272, 100, NULL, 1000, 'ForumWriteAccess', 4, 1002400, getdate(), 1,
getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (273, 100, NULL, 1000, 'ForumUploadAccess', 4, 1002400, getdate(), 1,
getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (274, 100, NULL, 1000, 'ForumAdminAccess', 4, 1002400, getdate(), 1,
getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (71, 26, NULL, 1000, 'Forum Read', 4, 200000, getdate(), 1, getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (72, 26, NULL, 1000, 'Forum Write', 4, 200000, getdate(), 1, getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (73, 26, NULL, 1000, 'Forum Upload', 4, 200000, getdate(), 1, getdate())

INSERT INTO [dbo].[AxCategory]
([CategoryID],[ParentID],[ExternID],[SequenceNr],[Name],[Level],[OrderNr],[Created],[PublicationState],[Published])
VALUES (74, 26, NULL, 1000, 'Forum Admin', 4, 200000, getdate(), 1, getdate())

 

NB! Newly created rights should be categories under ’Rights’ with ID = 26  because in the current example case they are applied in the Live System. To make available assignment of these rights via AxCMS interface they should also be added to the Management System’s database under the same root.

The last step in this workflow is binding rights and checkpoint categories together. For that, defined above checkpoints should be classified by proposed rights. The most evident way for that would be the following interconnection:

  1. ForumReadAccess - read, write, upload, administrate rights;
  2. ForumWriteAccess - write, upload, administrate rights;
  3. ForumUploadAccess - upload, administrate rights;
  4. ForumDeleteAccess - administrate right;

As it is seen ForumReadAccess checkpoint passes through only if the user has at least one of the read, write, upload or administrate rights. ForumWriteAccess checkpoint makes the access more strict, ignoring read right. ForumUploadAccess checkpoint can pass users with the upload or administrate rights. ForumDeleteAccess is only available for users with the administrate right. So the described above rights’ logical hierarchy is achieved! Of course, in overall it is not the main goal but quite understandable thing in case of forum application.
Suggested checkpoint-rights relations can be added to the database by the following SQL:

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (71, 271, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (72, 271, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (73, 271, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (74, 271, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (72, 272, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (73, 272, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (74, 272, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (73, 273, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (74, 273, 19, 3, getdate())

INSERT INTO dbo.AxElementCategory
(CategoryID, ElementID, ElementType, Direction, Created)
VALUES (74, 274, 19, 3, getdate())


NB!
There is no need to add the same entries to the Management System’s database if according rights will not be checked/controlled in AxCMS. Relations are retrieved during the checkpoints’ execution.  So if rights are applicable only in the Live System, their classifications with checkpoints in the Management System’s database are unnecessary.

Workflow (part 2)

The task of the second part of the workflow is to decide how to assign forum rights to a user. It is better to say that some mapping between forum threads and user roles/rights is required. Then, also, the questions may occur:
   How to protect content under forum threads in the Live System?
   Is it better to guard pages, controls or functions?
The answer to the last question is out of this tutorial because it is the problem of specific application design. Everyone decides himself where he puts checkpoints in his code. The problem now is to make clear the principle of using AxCMS.net security model in the most efficient way.
To the last point about the efficiency of AxCMS.net also belongs such thing that it is already possible after defining roles/rights, checkpoints and binding them together to use these concepts in the Live System. Maybe someone who uses AxCMS system in his project has already developed some other interface for managing user permissions. If not, then information below will be quite useful for showing how to use AxCMS for that purpose.

It was told in the previous chapters that objects (pages, documents etc) are not managed through AxCMS directly. In order to be able to modify the content of the Live System through the Management System, it (content) must be ‘categorized’ first. It is also quite good to use the same approach in the current tutorial example. As the rights are applied to forum threads, then it is possible to define them (threads) as categories too. Then these forum entities are the part of the CategoryTree and respectively are understandable by AxCMS system.

So there are four threads in the example forum: ‘Thread 1’, ‘Thread 2’, ‘Thread 3’ and ‘Thread 4’. Let’s add corresponding categories to the databases (NB! both Management and Live System databases must have these entries in such case). It is possible to add one more category ‘Forum’, joining categories Thread 1, …, Thread 4 together.

Example from categories.xml:

<Category name="Kategorien" categoryId="1">
<Category name="SpecialPermission for LS">
<Category name="Forum">
<Category name="Allgemeines">
<Category name="Thread 1" />
<Category name="Thread 2" />
<Category name="Thread 3" />
<Category name="Thread 4" />
</Category>
</Category>
</Category>
...
</Category>

    
The next step is optional. There is no difference under which tree, standard or specific, the subtree ‘Forum’ will be placed. For the management system administrator it is his own comfort problem. For example, ‘SpecialPermission for LS’ category (ID = 46) could be the parent for the ‘Forum’, as according by meaning, it suits the situation.
That’s all!

Summary

To integrate the AxCMS.net security model to the project and to use its concept entities for protecting Live System’s content, the next four steps should be performed:

  • Checkpoints worked out and added to the table AxCategory in the Live System’s database. If the same checkpoints are used by AxCMS, then Management System’s database should also contain them.
  • Permission categories (roles or rights) should be added to the AxCategory tables in both Live and management systems’ databases.
  • Permissions-checkpoints relations should be saved in the table AxElementCategory in the Live System’s database, and maybe also in the management system’s database if corresponding checkpoints have to be used by AxCMS.
  • Corresponding to the Live System’s content categories should be added to the both Live and Management Systems’ databases, because the permissions’ assignment is performed in the Management System and their check – in the Live System. Categories should be a part of Live System’s standard or specific tree, to be available for managing through AxCMS.

After execution of the four steps described above, newly created categories should appear in the AxCMS interface. If so, then they are ready to use. Go to ’Administrate rights...’ section of member profiles’ overview page. It should look similar to this:

Select a category under the root ’Forum’ and assign an appropriate rights to it. Selected rights for the current user are activated after saving. To check them in the Live System, checkpoints of the following type could be placed into the code:

. . . (new AxCategoryCheckPoint((int)ForumCheckPointID.ForumReadAccess, boardID)).Check(user) . . .

NB! There are checkpoints of other types are also provided by AxCMS.net (see Definitions). Which of them to use and when, depends on situation. In current example mostly AxCategoryCheckPoints are used. But if it is decided to apply, for example, roles for forum protection, then maybe simple AxCheckPoints are more suitable.

Troubleshoot

The process of permission check is the following: by the checkpoint’s id all roles and rights, that are needed for passing through, are determined. Then it is found out if the current user has at least one of required permissions assigned.
User permissions are saved in the AxUserRight table. Users’ (management system users’) roles/rights ids are held in the Management System’s database, and members’ (Live System users’) – in the Live System’s database accordingly.
So if in some situation a user has but doesn’t pass some of the checkpoints then:

  1. check, if permissions are added to the AxUserRight table, and are saved in the correct database;
  2. check, if permissions-checkpoints mappings are saved properly, and again are held in the correct database.

NB! When new categories are added to database, AxCategoryTree needs to be regenerated (table AxCategoryTree). The site application needs also be restarted (actually restarting IIS is enough).