You are reading the documentation for an outdated Corteza release. 2024.9 is the latest stable Corteza release.

Security

One of the main focus when working with data in the enterprise environment is the data integrity and security.

Corteza takes this seriously and defines a powerful permission system that allows you to control access to any resource, being an application or a single module field.

Users and Roles

Corteza uses Role-based access control (RBAC), meaning we define access control permissions to roles (we specify what roles are allowed to access what resources). When a user is assigned a set of roles (becomes a role member) the user inherits the permissions that the assigned roles define.

See access control check flow for details on how the access control functions.

Every user is automatically a member of the "Everyone" role.

The first registered user is automatically promoted to an "Administrator" role.
Each permission rule can be in one of the two access states:

  • allow: the role is allowed to access the specified resource.

  • deny: the role is not allowed to access the specified resource.

It’s good practice to limit your users a much as possible to help avoid security breaches.

Access control check flow

When checking if a user can perform a specific operation, the following check occurs:

  1. Can the assigned roles perform the requested operation for a specific resource?

  2. Can the assigned roles perform the requested operation for all resource of the given type?

  3. Can everyone perform the requested operation for a specific resource?

  4. Can everyone perform the requested operation for all resource of the given type?

For each step:

  1. If any role (or everyone) in the 1st or 2nd step has an explicit deny, the check ends and disallows the operation.

  2. If at least one role (or everyone) has an explicit allow, the check ends and allows the operation.

  3. If there is no explicit allow or deny, continue to the next step.

If all four steps complete without an explicit allow or deny, the system default is used which is deny for most cases.

Modular design

We suggest a modular role design, where we define multiple roles with a smaller set of permissions. For example:

  • CRM admin: only provides administration privileges for the CRM,

  • Messaging admin: only provides administration privileges for the messaging,

  • System admin: only provides administration privileges for the system.

Then we can easily "stick" these roles together when creating users.

There are no limitations to how many roles we can have, but don’t go overboard. Having a new role for each rule will be a nightmare for maintaining.

DevNote take note of the impersonation feature.