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

The Security Model

Corteza defines a RBAC access control facility. RBAC uses the roles of the given user to determine whether they have access to a given resource.

Most of the Corteza resources allow you to define which roles are allowed to access the resource. Locate the permissions button in the user interface in order to manage the resource.

Annotated image

Refer to Resource Operation Reference for the complete reference of available RBAC rules.

Corteza’s RBAC facility uses a "flat design" which removes role hierarchy (two roles can not explicitly define a parent/child relationship).

Context role membership allows you to dynamically assign users to roles based on the defined set of rules.

While access control for specific records is supported, access control for particular fields of particular records is not.

You can bypass this limitation by using context role membership and module filed rules.

Access Evaluation Flow

When access is evaluated, the system collects all users' roles and RBAC rules as a part of the security context. The order of rule evaluation is based on role importance and resource specificity.

If a user is a member of a bypass role, all operations are permitted without any restrictions.
Access evaluation flow:

  1. If any rule defines an explicit deny, the evaluation results with deny.

  2. If at least one rule defines an explicit allow, the evaluation results with allow.

  3. If there are no explicit allow or deny rules on the current level, the evaluation continues to the next set of rules based on role importance.

  4. If the evaluation cannot find an explicit allow or deny rules, the evaluation results with deny.

Role Importance

Role importance defines the order in which roles and their corresponding rules are evaluated.

Role importance for authenticated users:

  1. bypass roles,

  2. context roles,

  3. common roles,

  4. authenticated roles.

Role importance for unauthenticated users:

  1. anonymous roles.

Resource Specificity

Resource specificity defines the order in which rules for the corresponding resources are evaluated. Resource specificity is defined based on how specific this rule is to this resource.

As an example, a rule that allows users to create records on the account module in the CRM namespace is more specific than the rule just on the CRM namespace.

Such specificity allows you to deny access to all but one resource of the given type. To exemplify; you could deny access to all namespaces and allow access to just one namespace.

Role Types

A list of bypass, authenticated, and anonymous roles is provided in the system configuration and can not be changed at runtime. Refer to DevOps guide for details on how this can be done.

These roles can not be modified or renamed.

If you wish to alter the roles, you can either:

  • temporarily change the role list, edit the roles, revert the role list changes,

  • change the provision scripts to supply the required names at the initial Corteza run.

Bypass

Bypass roles allow their members unlimited access to Corteza with no permission checking.

Out of the box, Corteza defines the default bypass role named "Super administrator". Your system administrator can change the set of bypass roles in the .env file. The roles that are defined as authenticated have restricted editing options.

Common Roles

Common roles are any additional roles defined in the administration panel, such as a CRM admin and application builder.

Contextual Roles

You can not use contextual roles within auth clients, nor can they define an explicit member list. Contextual roles are assigned to users based on the operation and the context.

Contextual roles define a series of expressions, which determine when the role is assigned to the user based on the operations' context.

Each role can define an expression for each resource type. Each role can only use a resource type once.

Contextual roles are hidden from resource permission screens if the role does not define an expression for that resource. For example, a record specific role is not shown on the module permission screen.

For example, a certain case of use would allow us to use contextual roles to permit resources owners to perform operations they normally wouldn’t have, such as editing and deleting said resources.

Refer to the Contextual Role Evaluation for details.

Contextual roles are currently supported for:

  • records,

  • workflows,

  • auth clients.

Authenticated

Authenticated roles are implicit, meaning that users can not explicitly be set as role members.

Out of the box, Corteza defines the default authenticated role named "Authenticated". Your system administrator can change the set of authenticated roles in the .env file. The roles that are defined as authenticated have restricted editing options.

If the user is authenticated with Corteza when they are accessing a resource, the system additionally assigns them authenticated roles.

Anonymous

Anonymous roles are implicit, meaning that users can not explicitly be set as role members.

Out of the box, Corteza defines the default anonymous role named "Anonymous". Your system administrator can change the set of anonymous roles in the .env file. The roles that are defined as anonymous have restricted editing options.

If the user is not authenticated with Corteza when they are accessing a resource, the system additionally assigns them anonymous roles.

Important Notes

System Setup

Corteza defines a series of system role types: bypass, authenticated, and anonymous. System role types are defined on the server configuration level, and cannot be changed directly through the user interface.

If a role is assigned to one of the system role types, the editing is restricted. If the role is somehow removed or changed to the extent where the system can not identify it, the system should refuse to start.

The rationale behind such restrictions:

  • The configuration affects the RBAC facility and its setup process.

  • Systems that work with access tokens need to be aware of such changes.

  • The security model on this level rarely changes, and the change is drastic when it does.

Bypass RBAC Roles

If a role is assigned as a bypass, it may not appear as any other role type. In the occasion where this is not the case, the system will refuse to start.

Only members of the bypass role may manage the membership of the bypass role.

Bypass roles can be listed on auth clients as permitted or prohibited roles but are silently ignored when defined under forced roles.

Authenticated and Anonymous

Authenticated and anonymous roles may not appear in any auth client security role lists (the allowed, denied, and forced roles) and are silently ignored.

Glossary

A user

A user is an entity that is accessing Corteza. A user can be a member of security roles and cannot get permissions directly without an assigned role.

A role

A role represents a set of users and a set of permissions over resources.

Corteza’s RBAC implementation defines a flat structure that removes role hierarchy (two roles can not explicitly specify a parent/child relationship).

Access

Defines if the rule permits (allow) or denies (deny).

A resource

A structured piece of information stored within Corteza that we may or may not control access to. Each resource belongs to a component and has a unique type.

A resource type

A resource type defines the structure of information within the Corteza component.

Operation

Defines what operation the given RBAC rule defines access to.

RBAC rule

A RBAC rule combines operation, role, access, and resource. It defines what someone can (or can not) do on one or more resources inside Corteza.

Security session

A security session is created when a user requests to access Corteza.