Ever increasing functionality and constantly expanding developer support are the most vital features of an open source Content Management System. But this freedom also poses a threat to the security of the websites and confidential databases within the system.

Keep in mind that open source systems are exactly what the name suggests; open for each and every person in the whole wide world. Therefore it is a vitally important factor for CMS’ to utilize the safest security measures while the storage and processing of data. 

DotNetNuke – Unbeatable, Unbreakable:

Many CMS’ have been known to run into some harmful security issues because their security architectures tend to be weak, clumsily-made and run short of extensibility. But wait! Gather round everyone because DotNetNuke has come to the rescue!

The single most salient feature of DotNetNuke that is more crucial than all the rest is its robust security architecture. DNN’s security architecture has evolved into the essential backbone of the CMS over the past ten years. Every nook and cranny of DotNetNuke’s system has security implications, and the architecture is optimized to serve both the end-users and developers. 

Understanding the System:

Now let me explain DNN’s Security Architecture in simple words. The architecture is comprised of a number of different objects. There are ‘Entities’ which include objects like Pages, Modules and Folders, whose access needs to be controlled. And on the other end are the ‘Users’ who need the proper authorization to perform certain actions like Viewing, Editing or Deleting information. So these two sides are linked together through a system called ‘Permissions’. It is easy enough to understand that Permissions indicate which User is permitted to perform actions on the data and who is not.

But if you want to look at it from a technical perspective, then it’s simple enough to say that the security architecture of DotNetNuke is broken down into three basic parts: first is the ‘Database Layer’, second is the ‘Business Layer API’ and the third is ‘User Interface Layer’. These layers work interdependently to provide the impeccable security architecture that DNN is so proud of. 

The Database Layer provides a ‘Permissions Table’ where each nitty-gritty security contract is registered. This table specifies the abilities and authorization levels of the users to VIEW a page. This table can register both the central framework permissions and also the custom permissions for each particular module.

Now the Business Layer API handles the heavy-duty stuff related to the administration of permissions information that who can add, update or delete the data. If you see it from a developer’s perspective then the most important Application Programming Interface calls are those which execute the definite user authorizations.

And lastly, the User Interface Layer provides the ‘Network Controls’ for the management of permissions. This layer involves the use of the ‘PermissionsGrid’ control which contains all the necessary permissions’ functionalities along with a number of methods that can be overridden and can be leveraged to create consequent permissions management grids for any entity in the system.

The killer combination of these three layers of the DNN Security Architecture results in a more stress-free and protected experience for both users and developers.