Permissions
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.
|
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 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)
-
System Permissions
To access System Permissions, go to Admin Panel and click on "Permissions" in the "System" section.
System Service
In this section you control overall access settings and usage of Admin Panel.
You can set permissions to:
-
Create new role/user/application/automation scripts
-
Allow reminder assignment
Corteza Elements
-
Access/update/delete any application
You can set rights to access any application to everyone and explicitly forbid it per few applications in the list of applications.
-
Access/update/delete any user
If a user doesn’t have access to read any user, they’ll see their IDs instead of a name in surname (for example in Messaging application)
-
Suspend/un-suspend any user
-
Access/update/delete any role
-
Manage members for any role
-
Read/update/delete any automation script
-
Run any trigger on any automation script
Any access you grant in this section can be overridden per individual element.
Low Code Permissions
To access System Permissions, go to Admin Panel and click on "Permissions" in the "Low Code" section.
Low Code Service
In this section you can control who can access Low Code, who can manage settings and who can create namespaces.
Please note that permissions are fine-grained, meaning if you allow users to access namespaces, they still need explicit allowance to read pages, modules and fields.
Namespaces
In this section you can control which role can:
-
Have read access to any namespaces
-
Update/delete/manage any namespace
-
Create modules/charts/pages/automation scripts
Any access you grant in this section can be overridden per individual namespace.
Messaging Permissions
To access System Permissions, go to Admin Panel and click on "Permissions" in the "Messaging" section.
Messaging Service
In this section, you can control who can access Messaging app, manage Messaging settings and who can create public/private/direct channels.
We recommend this permissions to be allowed to Administrators and Messaging Admins only.
Channels
In this section, you have full control over which role can to the following:
-
Update/View/Join/Leave any channel
-
Delete/un-delete/archive/un-archive any channel
-
Manage members and attachments of any channel
-
Send/Embed messages, Reply in threads
-
Send attachments to channels (if they’re enabled in the Messaging settings)
-
Update/delete own/all messages
| If no explicit "Allow" or "Deny" rules are set, we use a set of business logic rules as well. |
If a user doesn’t have explicit allowance to delete any channel, but they can create a public channel, they we’ll still be capable of deleting this channel as they’re the owner of it.