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

Security

One of the main focuses when working with any kind of data in the enterprise environment is the data integrity and security, especially when working with sensitive information. 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.

Resource level permissions are described in detail in the following sections. This section merely outlines the system.

Corteza uses Role-based access control (RBAC) as a method of restricting access based on the roles of individual users within the system. RBAC lets users have access rights only to the parts of the system/application they need and prevents them from accessing information that doesn’t pertain to them. By default, a user is assigned to "Everyone" role which is very limited due to security (in case someone uninvited registers to your system, they won’t see any data, Messaging channels, list of applications, etc.).

The first registered user is granted admin rights by default.

Each permission can be in one of the following states:

Inherit

To check the setting in the layer above. For example: if an individual application has access permissions set to "Inherit", it will use the permission set for All applications (default: "Deny"). Explicit "Allow" or "Deny" always override the Inherit value,

Allow

To allow the role to perform the operation over a specified resource,

Deny

To deny the role to perform the operation over a specified resource.

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

Permissions setting is fine-grained, meaning the system administrator can control permissions on several layers, for example:

  • which role can access applications

  • which role can read the data

  • which role can edit the data

  • which role can access admin area, etc.

Access control check flow

The overall flow of verifications if a role has access to perform an operation on a resource is the following:

  • Can this combination of roles perform an operation on this specific resource

  • Can this combination of roles perform an operation on any resource of the type (wildcard)

  • Can anyone/everyone perform an operation on this specific resource

  • Can anyone/everyone perform an operation on any resource of the type (wildcard)

The check will return:

  • Inherit when:

    • No roles are given

    • More than 1 role is given and one of the given roles is Everyone

  • Deny when:

    • There is one rule with Deny value

  • Allow when:

    • There is at least one rule with Allow value (and no Deny rules)

Permissions in the Admin Panel are general and can be overwritten.

Tips and tricks

Modular approach

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 is no limit to the number of available roles or to the amount of members a role can have.