Skip to main content
xorlab Security Platform defines the concepts of Roles, Permissions and Scopes:
  • A Permission denotes an atomic action (in terms of access control) bound to a specific Scope.
  • A Scope limits a permission to a specific context. For example, a user’s current tenant Scope may constrain a Permission to not extend beyond their own tenant.
  • A Role is a set of Scopes with Permissions. If needed, Roles can be arbitrarily composed and assigned to users.
Roles can be assigned to users but permissions cannot be directly assigned to users. Each subsystem of xorlab Security Platform could define its own set of permissions, although currently only the XCC (Control Center) defines such permissions by default. xorlab Security Platform is shipped with a set of predefined roles. However, the configuration allows for the creation of additional roles with arbitrary permission mappings.

Assigning Roles to Users

Role assignment is managed by the authorization system, which is part of the authentication process. Typically, this occurs outside the xorlab Security Platform (XSP) in an Identity Provider (IdP), an LDAP directory, etc. However, XSP supports configuring role mappings. This allows roles defined within an organization to be mapped to XSP roles, whether predefined or custom. To configure role mapping, you need to edit the auth.yml file for each authentication backend. Each backend that supports role mapping uses the roleMapping configuration parameter. Please refer to the Authentication page for additional information.

Predefined Roles and Permissions

Roles

The xorlab Security Platform defines a set of permissions that can be mapped to roles. XSP comes with a default set of roles, each of which is mapped to a predefined set of permissions. Administrators can create new roles and define their associated permissions. However, the permissions of predefined roles cannot be changed.

Specification of a Custom Role

To specify a custom role, add it to roleToPermissionMappings in xcc.yml. You can find the list of available permissions in the Permissions-Role Matrix. A custom role consists of so called grant definition. Hint: You can query your current permissions as described here.

Grant Definition Syntax

Notice: Omitting the <scopeDefinition> implies a global scope (full, unrestricted access) for a specific permission.

Example Grant Definitions

Example Role Mapping

Permissions-Role Matrix

This table shows whether a specific built-in role has a Permission or not and if so with what Scope.
  • Table entry global means that the role has unrestricted access for a specific permission.
  • Table entry tenant:primary means that the role has access for a specific permission but only within the bounds of the current user’s tenant.
  • A missing table entry indicates that the role does not have that permission at all.