We can all agree that security is crucial in online services, but how do we know when a website is truly secure? It's not as obvious as when you lock your car, throw a jacket over your valuables, and park it in a supervised parking garage. Website and software security is abstract, and it can be difficult to see when you've taken all the appropriate security measures.

This posts aims to illustrate a key security feature websites need to have, and demonstrate how the feature works within eZ Systems.

When we considered a security model for eZ Publish Platform there were three underlying factors that we wanted to include in our final design decision:

• Secure by default: no access is granted unless explicitly defined otherwise
• Pluggable permission model: you can build your own permissions or custom developments because the platform (which includes the permission policies) are extendible
• Decouple permissions: make users and permissions disparate, aka proper role-based architecture. This differs from Windows, where each piece of content defines who can access it. With eZ, you define permissions based on content type, making the system far more scalable and manageable.

The diagram below shows how these factors function in eZ.

Secure by default - Role-Based Permissions

The core of eZ's permission model is divided into two: permission management (roles and policies) and user management (users and user groups). This design assures that you have decoupling between user management and permissions, a concept that allows separate user(s) to create and assign permission sets from the user(s) allowed to create users and user groups.

This overall design adds a formidable layer of security: it decreases the number of users who can work with permissions.

Even the anonymous visitors, i.e. visitors not logged in, have roles assigned to them. In eZ, the role associated to a user defines any function the user can perform. If no functions are defined, the user can access nothing.

Every access has to explicitly be defined, including whether users can read any content from a stand section or view images from the media repository. This design concept means that you, the admin, both can see what a specific role or user can access, and that you have to explicitly define if those users should have access to a function or specific content type.

The structure in eZ is divided into modules and functions and allows for custom plugins to use the same permission system. Also following the secure by default access, new modules that are developed have to be explicitly granted access in the permission system - unless nobody gets access to use it.

For those familiar with Symfony, modules and functions can map to controllers and their actions; however, they can also be reused across several actions, providing reuse. As for limitations this works similarly to security voters, which are able to return three outcomes: Granted, Denied and Abstain, in cases where it does not apply. One big difference is that limitations are also applied to queries being done by the Search system, making sure content returned is accessible to the current user.

Hierarchical Permission Model

Besides being able to have a role-based permission system, eZ also has a model that allows for a hierarchical structure of users and user groups. The screenshot below shows a simple example of the user group structure.

As you can see, this a tree structure. One implication of this is that editorial users can be given specific inheritance of permissions, which facilitates the user management experience.

Also note that there is a separate user group for anonymous users. By default, this anonymous status only appears when one defined user is assigned for another visitor who is not yet authenticated.

You can further define and customize this feature for a finely grained control over what a unique user or group has access to. For example, you can write specific access rules for various languages or different rules for mobile and desktop visitors.

When you are looking at CMS solutions, or other online solutions, check out permission system in detail. Your vendor should explain what mechanisms are used to achieve a secure system and why. If they do not, you should look for another who does. If their answer isn't sufficient, continue your search.