Skip to content

IDV Platform RBAC Key Concepts

Role-Based Access Control (RBAC) allows Platform Administrators and other authorized users to manage user access to IDV Platform functional areas such as Workflows, Sessions, and Profile groups. Access to these areas is determined by user permissions.

This page explains the RBAC permission model, its key components, how permissions are granted, and the rules that govern access to platform resources.

For step-by-step instructions on creating users, managing groups, configuring roles, assigning permissions, and practical examples, see the Role Management Guide.

Why Use RBAC

RBAC helps you protect sensitive information, prevent unauthorized actions, and ensure that users can only view data and perform actions necessary for their tasks.

Key Concepts

User is a person who logs in to the IDV Platform Back Office. You can find a detailed definition of a user in the IDV Platform Introduction article.

Permission is an access right. It defines which operations a user can perform, within which scope and on which entities.

Every permission includes three mandatory elements:

  • Scope: represents a functional area where the permission applies. For example, session, workflow, roles.
  • Operation: defines which action or actions can be performed. For example, read, create, update.
  • Entity ID: a unique identifier of a specific resource, such as a session, workflow, or group, to which the permission applies. When selecting entities in the Back Office UI, users see entity names where available; otherwise, the UI displays entity IDs.

Role is a named collection of permissions, such as Admin, Operator, or Auditor.

Group is a named collection of users, such as Compliance Team or Support Team.

How Access Is Granted

Access through groups and roles

The following diagram shows how users inherit permissions through groups and roles in IDV Platform.

The key principle is that users inherit permissions only through groups with assigned roles. You cannot assign roles directly to users.

flowchart TD
    U["User"]
    GA["Group A"]
    GB["Group B"]
    R1["Role 1"]
    R2["Role 2"]
    R3["Role 3"]
    P1["Permissions"]
    P2["Permissions"]
    P3["Permissions"]

    U --> GA
    U --> GB
    GA --> R1
    GA --> R2
    GB --> R3
    R1 --> P1
    R2 --> P2
    R3 --> P3

In this example:

  • The user belongs to Group A and Group B.
  • Group A has two roles: Role 1 and Role 2. Group B has one role: Role 3.
  • Each role has its own set of permissions.

The user inherits the combined permissions from all roles assigned to Group A and Group B.

For more information, see Roles and Groups.

Initial Admin access

During the initial IDV Platform setup, the default Admin account is automatically created and added to both the All Users group and the Admin role group. Through membership in the Admin group, the account inherits the built-in Admin role and its permissions.

For more information, see Admin.

New user access

Newly created users are automatically added to the All Users group, which has no assigned roles and grants no role-based permissions.

To access IDV Platform functional areas, users must be added to a group with assigned roles.

For more information, see Default Groups.

Creator Ownership

Creator Ownership grants users full access to entities they create, independently of their inherited permissions. This access persists regardless of changes to group membership. However, Creator Ownership does not override mandatory system restrictions.

For more information, see Creator Ownership.

General Rules and Constraints

  • Permissions are granted exclusively through roles assigned to groups.
  • Permissions cannot be assigned directly to users.
  • When a user is removed from a group, they lose permissions inherited exclusively through that group. Permissions inherited through other groups remain available.
  • When a role is removed from a custom group, all group members immediately lose the permissions provided exclusively by that role.
  • Users, including Admin, cannot modify their own accounts or add or remove themselves from groups.
  • Users cannot change the roles assigned to groups they belong to.
  • Users cannot create roles with permissions that exceed their own.
  • Users with the roles:assign:* permission can assign any role, including roles with broader permissions than their own. To view roles in the dropdown list, users also need roles:read:* or roles:read:<role_id> permissions for the relevant roles.

Next Step

Explore the available scopes and operations, along with permission examples, in Permissions: Scopes, Operations and Entities.