RBAC Delegation

Why RBAC Sub-Delegation Matters

Sub-delegation gives users better control over permissions and prevent inefficiencies or security risks. Currently, when an Admin delegates administrator permissions to a sub-admin, the sub-admin gains full access to the entire system and can control both their superiors’ and subordinates’ setups within the organizational unit. This creates a serious security loophole. Additionally, any internal service account that a user creates becomes visible to all users with application access, without any ownership-based restrictions. This lack of separation raises security and privacy concerns, especially in environments where multiple teams or users share the same tenant but require clear boundaries for responsibilities and data access.

What is RBAC Delegation?

Sub-delegation enables a user to pass on their permissions to others, essentially granting them the authority to assign roles and permissions the original user possessed.

Delegate Admin allows the creation of a hierarchical user group structure where administrators can delegate permissions to second level of administrators, allowing them to manage user groups, users, roles, and resources without having the ability to modify super admin roles or peer roles. The feature is accessible via a toggle button in the user group inventory and is only visible to super admin users.

Delegated admins can create new user groups, roles, and resources, which are then automatically visible to them and the super admin, but not to other users.

Delegation Hierarchy Overview

AppViewX Admin (Pre-shipped Admin / Level 0):
  • Has full access across the system.
  • Can assign delegated user groups (e.g., PKI Admin Group, CERT Admin Group).
  • Can map existing user groups to delegated hierarchies.
  • Maintains cross-hierarchy visibility and control.
Delegated Admin (Level 1 – e.g., PKI Admin Group, CERT Admin Group):
  • Operates in an isolated environment within their group’s boundary.
  • Can manage users, groups, roles, and resources that are part of their hierarchy only.
  • Delegated users cannot manage or edit users/groups in peer or parent hierarchies
    • Visibility of upper/peer levels is read-only
    • Visibility of own permissions is read-only
Users outside of delegated groups:
  • Cannot manage user groups, even if they hold RBAC ACF permissions.
  • Receive the error: "You do not have access to manage User Groups. Contact your Admin."
  • May still manage users, roles, and resources as permitted by ACF, but cannot associate these entities with any user groups.
  • Cannot apply any changes to user groups due to lack of group management permissions.

Impact of Sub Delegation

  • Disables existing RBAC user groups, shifting permission management to the delegation hierarchy.
  • Determines user access based on their position in the delegation tree.
  • Blocks users with RBAC ACF but outside delegated groups from managing user groups, showing a UI error to contact the Admin. They can still manage users, roles, and resources as allowed by ACF.
  • Fully isolates delegated units, preventing visibility into peer groups or other hierarchies.
  • Restricts delegated admins from editing self, upper-level, or peer-level entities; these appear as read-only in the inventory.
  • Limits user group association to lower-level entities during mapping.
  • Maintains ownership and delegation hierarchy for all entities.

Impacted Use Cases

  • Use cases related to modules like AI, Certificate Management, Workflow, Dashboards, Import/Export.
  • Use cases for resource handling across CERT, Devices, and Workflows will follow the delegation boundaries.

Inventory-Level Behavior

User Inventory:
  • A delegated admin sees has access to users created by or under their delegated group.
  • Users from other delegated groups or higher levels are completely hidden.
User Group Inventory:
  • Delegated admins can only view or manage user groups they created or that were assigned under them. (the assigned groups can be shown in profile section if not inventory)
  • Peer or upper-level user groups are not visible or editable.
Role Inventory:
  • Delegated admins can only view, assign, or modify roles created under their own delegated group.
  • Roles from other delegated groups are completely hidden.
  • Role assigned to delegated admin can be shown as read only (to view and understand the permissions)
Resource Inventory (Device, Certificate, Workflow Studio, Workflow Request):
  • Delegated admins can view and manage only those resources created within their boundary.
  • Resources from other delegated groups or superior levels are not listed or accessible.
  • Resources assigned to the delegated admin can be shown as read only (to view and understand the permissions)

Impact on RBAC ACF Users Outside Delegated Groups

Users who have Access Control Filters (ACF) through RBAC but are not part of any delegated user group experience the following behavior when delegation is enabled:
  • User Group Management Blocked: Cannot create, edit, or delete user groups, even with ACF permissions; UI shows an error message.
  • Limited Access to Entities: When a user belongs only to non-delegated user groups and delegation is enabled they have the following behaviour:
    • Can create and manage only their own Users, Roles, and Resources (if allowed by ACF)
    • Inventory appears empty by default until entities are created
    • Entities remain hidden from other users, regardless of RBAC ACF.

Impact on Users in Both Delegated and Non-Delegated Groups

When a user is a member of both delegated and non-delegated groups, the delegated hierarchy takes precedence as the active scope. In this scenario:
  • Access is limited to the hierarchy of the delegated group.
  • Permissions from non-delegated groups are disregarded.
  • The user can view, manage, and assign users, roles, user groups, and resources only within the delegated scope.
  • Roles and resources from non-delegated groups cannot be created or assigned outside the delegated boundary.

This enforcement ensures strict isolation between hierarchies and prevents privilege escalation or leakage across scopes.