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

Overview

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.

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.

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.

Working with permissions in Admin Panel

Each user can be a member of multiple roles. We suggest having "modular" approach, so creating multiple smaller roles (i.e. Messaging admin, CRM admin) and then stacking them to cover all the parts of the system where a user needs access.

Admin can create unlimited amount of roles. Permissions system in the Admin Panel is a playground, where you bring each role on the table, adjust the permissions and save it. More details in the following chapters.

  • Click on a permission/role cell set permission to "Allow"

  • Using ALT + click on permission/role cell set permission to "Deny"

Permissions check in the System

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)

Permissions in the Admin Panel are general and can be overridden per individual application/namespace/etc. For a better overview, we suggest you first set permissions on this level and then go lower on the hierarchy.

Inherit value

Inherit value always checks 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.

In practice, that means that check verifies if any of given roles has permission to perform an operation over a resource

  • Will return Inherit when:

    • No roles are given

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

  • Will return Deny when:

    • There is one rule with Deny value

  • Will return Allow when:

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