rbac - DQLabs PRIZM

Overview

The Prizm platform utilizes a flexible Role-Based Access Control (RBAC) system with optional Attribute-Based Access Control (ABAC) filters. This model provides granular control over resource access while remaining operationally manageable for enterprise administrators. The RBAC system enables organizations to align access controls with their specific organizational structure and security requirements through custom roles, hierarchical inheritance, and tag-based filtering.

Core Principles

Principle	Description
Resource Independence	Domains, Products, Apps, and other resources are independently secured
Hierarchical Inheritance	Permissions cascade based on resource relationships
Role Precedence	Higher-priority roles take precedence in access decisions
Tag-Based Filtering	Additional constraints based on data classification tags
RBAC + ABAC	Role-Based Access Control with optional Attribute-Based filters (tags, ownership, sensitivity)
Highest-Role-Wins	When multiple roles apply, the highest permission level takes precedence
Loosely Coupled Resources	Domains, Products, Apps, Tags, and Connections are independently assignable
Custom Roles	Administrators can define tailored roles for advanced use cases

Key Entities

Entity	Description
Member	People or agents interacting with the system, authenticated via SSO or direct login
Groups	Logical collections of users (e.g., Marketing, Engineering) that map to SSO groups
Roles	Abstract responsibilities (Owner, Steward, Member, Admin) with defined permission sets
Permissions	Atomic actions (read, write, approve, manage security) defining what operations are allowed
Assignments	Mappings of roles to users/groups for specific resources with optional constraints
Resources	Domain, Product, App, Connection — loosely linked with Tags as optional constraints

Access

The Prizm platform uses a flexible Role-Based Access Control (RBAC) system with optional Attribute-Based Access Control (ABAC) tag filters. The Access module is the central hub for managing all of this — Members, Groups, Roles, Permission Sets, and Audiences are all managed here.

The Access dashboard surfaces five key counters at a glance:

Entity	Count	Purpose
Member	28	Individual users in the organization
Group	2	Collections of users sharing a role assignment
Role	4	Named permission profiles (Owner, Steward, User, custom)
Permission Set	4	Sets of toggled permissions (420 total defined)
Audience	2–3	Notification channel subscriber groups

Members

The Member tab lists every user in the organization along with their assigned role, active status, MFA enrollment, and SSO status.

Member Fields

Column	Description
Email	User’s login email address
First Name / Last Name	Display name (populated from SSO or manually)
Role	The role assigned to this user — Owner, Steward, User, or a custom role
Status	Toggle — active (dark) or inactive (grey)
MFA	Whether multi-factor authentication is enrolled for this user
SSO	Whether this user authenticates via Single Sign-On
Action	Copy assignment, view details, or delete the member

Adding a Member

Click the ⊕ icon in the top-right of the Member section. You will be prompted to enter an email address and select a role. On first login, the user receives an invite email.

The Owner role cannot be deleted or downgraded by anyone other than another Owner. At least one active Owner must exist in every organization.

Groups

Groups let you assign a single role to a collection of users. When a user’s group membership changes in the identity provider, their Prizm permissions update automatically on next login.

Group Fields

Column	Description
Name	Unique group name, editable inline
Description	Optional free-text description of the group’s purpose
Role	The role applied to all members of this group
Users	Avatar stack showing assigned users; click ⊕ to add more
Status	Active / inactive toggle for the entire group
Action	Delete the group

Group vs. Direct Assignment

Scenario	Recommendation
Stable team with a shared role (e.g., all Marketing → Steward)	Use a Group
Individual exception or temporary elevated access	Use a direct Member assignment
IdP-synced department structure	Use Groups mapped to SSO groups

When a user has both a direct role assignment and a group role assignment, the highest-priority role wins.

Roles

Roles define a named permission profile. Prizm ships with three built-in roles and supports custom roles created by administrators.

Standard Roles

Role Definitions

Role	Priority	Permissions Summary
User	1	Read-only for non-sensitive assets; can request access
Steward	2	Limited to assigned resources; can edit metrics/sources, but not security
Owner	3	Full control over owned domains, applications, and products; can manage semantics, metrics, data sources, security, and approve all changes.
Custom	5+	Tailored by admins (e.g., Data Scientist, ViewerPII) with specific permission filters

Custom Roles

Custom roles (e.g., cx_role) are created by administrators and can be tailored with any combination of permissions from the Permission Set. Custom roles are assigned a priority of 5+ and appear with both edit and delete actions in the Role table. To create a custom role:

Click ⊕ in the Role section
Enter a name and optional description
Select the Permission Set to associate with this role
Save — the role is immediately available for assignment to members and groups

Deleting a custom role immediately removes it from all members and groups currently assigned to it. Users will fall back to their next highest active role.

Permission Sets

A Permission Set defines exactly which actions are enabled for each role. The Permission Set view shows a toggle matrix — rows are permission types and columns are the available roles (Admin, Editor, Viewer, and any custom sets).

Reading the Matrix

Dark toggle (●) — permission is enabled for this role
Light toggle (○) — permission is disabled for this role
Each row is a TYPE + ACCESS combination (e.g., ACCESS › Approve, ALERT › Create)

Default Permission Set Coverage

The four built-in permission sets cover 420 permissions across 25 resource types. The table below summarizes what each role can do by default.

Permission Set	Typical Role	Default Capabilities
Admin	Owner	All permissions across all types enabled
Editor	Steward	Create, edit, view; limited approve; no delete of core entities
Viewer	User	View only across most types; can request access

Permission Set Matrix

Each Permission Set (Admin, Owner, Steward, Member, Custom) can be assigned with one to many permissions sets and its relevant access.

Permission	Admin : 4	Owner : 3	Steward : 2	Member : 1	Custom : 5
Create/Edit Security	✅	❌	❌	❌	Configurable
Create/Edit Semantics	✅	✅	❌	❌	Configurable
Create/Edit Sources	✅	✅	✅	❌	Configurable
Create/Edit Metrics / Queries	✅	✅	✅	❌	Configurable
Approve Resources	✅	✅	✅	❌	Configurable
View / Request Access	✅	✅	✅	✅	Configurable

Permission Type Reference

The following table lists every permission type and the actions available for each. This set of permission sets are grouped under a particular permission and that can be tied to a resource assignment.

Resource Type	Available Actions
Access	approve, create, delete, edit, view
Actions	create, delete, edit, view
Alert	approve, create, delete, edit, view
Analytics	approve, create, delete, edit, view
Application	approve, create, delete, edit, view
Asset	approve, create, delete, edit, view
Command Center – Jobs	view
Command Center – Logs	view
Command Center – Schedule	approve, edit, view
Command Center – Utility Import/Export	edit, view
Dimension	create, delete, edit, view
Domain	approve, create, delete, edit, view
Exception	edit, view
Field	create, delete, edit, view
Issue	approve, create, delete, edit, view
Metric and Queries	approve, create, delete, edit, view
Organization – Integration	approve, create, delete, edit, view
Organization – Overview	approve, create, delete, edit, view
Organization – SAML/SSO	edit, view
Product	approve, create, delete, edit, view
Setting	approve, create, delete, edit, view
Source	approve, create, delete, edit, run, schedule, view
Steward	approve, create, delete, edit, view
Tag	approve, create, delete, edit, view
Term	approve, create, delete, edit, view

Source is the only resource type with run and schedule actions in addition to the standard CRUD set. These allow a role to trigger data source syncs and set up recurring ingestion schedules independently of edit rights.

Access Evaluation Logic

When a request arrives, Prizm evaluates permissions in this order:

Identify the user

Look up the authenticated user and resolve all group memberships.

Collect role assignments

Gather every role assignment — direct (Member tab) and via groups (Group tab) — at the Application level.

Resolve the highest role

Apply the highest-priority role when a user has multiple assignments. Owner (3) beats Steward (2) beats User (1); custom roles at 5+ always take precedence.

Load the Permission Set

Fetch the Permission Set associated with the winning role and read the enabled toggles.

Apply tag constraints

If the assignment includes allow or deny tag constraints (ABAC), filter the resource list accordingly.

Enforce

Return the final access decision. Deny constraints always override allow, even when only a single resource carries a deny tag.

Role Consolidation: All applicable roles are collected from user and group assignments. The highest-priority role’s permissions take precedence. Tag-based filters then further refine which resources are accessible.

Assignment Structure

Access assignments follow a consistent JSON format that maps users or groups to roles on specific resources:

{
  "assignee_type": "user | group",
  "assignee_id": "<user_id or group_id>",
  "resources": [
    {
      "resource_type": "domain | product | app | connection",
      "resource": "<resource_id>",
      "resource_role": "owner | steward | user | <custom_role>",
      "role_priority": 3,
      "assigned_by": "<user_id>",
      "assigned_date": "2025-06-24T00:00:00Z",
      "resource_constraints": {
        "allow": ["tag1", "tag2"],
        "deny": ["PII"]
      }
    }
  ]
}

Key Rules

allow: ["*"] — grants access to all tag variants of the resource
deny: ["PII"] — blocks access to PII-tagged rows/columns even if other constraints allow
A deny on any one resource is honoured even when all other resources in the assignment use allow: ["*"]
Assignments have an optional expiry_date field for time-limited access grants

Assignment Examples

Owner of two domains (no tag restrictions) E.g., Bob is an Owner of Domain Customer360 and Domain Marketing

{
  "resources": [
    {
      "resource_type": "domain",
      "resource_role": "owner",
      "role_priority": 3,
      "resource": "Customer360",
      "assigned_by": "bob",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    },
    {
      "resource_type": "domain",
      "resource_role": "owner",
      "role_priority": 3,
      "resource": "Marketing",
      "assigned_by": "bob",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    }
  ]
}

Steward scoped to Internal-tagged resources only E.g., Sarah is a Steward of Product MarketingData but only for Internal-tagged resources

{
  "resources": [
    {
      "resource_type": "product",
      "resource_role": "steward",
      "role_priority": 2,
      "resource": "MarketingData",
      "assigned_by": "sarah",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["Internal"] }
    }
  ]
}

Group with PII denied across two resources E.g., Group Marketing has Member access but cannot see PII-tagged data

{
  "resources": [
    {
      "resource_type": "application",
      "resource_role": "member",
      "role_priority": 1,
      "resource": "ETL-Pipeline",
      "assigned_by": "priyam",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    },
    {
      "resource_type": "product",
      "resource_role": "member",
      "role_priority": 1,
      "resource": "MarketingData",
      "assigned_by": "priyam",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    }
  ]
}

Global Admin (full access, all resources) E.g., Peter is a global Admin

{
  "resources": [
    {
      "resource_type": "*",
      "resource_role": "admin",
      "role_priority": 5,
      "resource": "*",
      "assigned_by": "peter",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "allow": ["*"] }
    }
  ]
}

User denied for PII Data across all resources E.g.., Ashok is a global Steward but cannot see PII data

{
  "resources": [
    {
      "resource_type": "*",
      "resource_role": "steward",
      "role_priority": 2,
      "resource": "*",
      "assigned_by": "ashok",
      "assigned_date": "2025-06-24",
      "resource_constraints": { "deny": ["PII"] }
    }
  ]
}

Even if only one resource carries a deny constraint while others are tagged as allow, the deny takes precedence for that resource. Deny constraints are always enforced.

Database Schema Reference

Schema Components

Table	Purpose
`users`, `groups`, `user_groups`	Identity model for user and group management
`roles`, `permissions`, `role_permissions`	Role definitions with associated permission sets
`assignments`	Grants roles to users or groups scoped to specific resources
`resources`	Flattened table of all resource types (domain, app, tag, etc.)
`role_precedence`	Priority ranking for conflict resolution
`resource_tags`, `app_domains`	Optional mappings between loosely coupled assets

Assumptions

Assignments exist at either User or Group level, identified by the assignee_type value ("user" or "group").
User-level assignments are implemented in application code by referencing the user_groups table, which stores user-group mapping information.
Access constraints are applied at the resource level (e.g., Domain: "Marketing", Product: "SAP_Prod").
The Assignments table contains only one record per user. The assignee_id field serves as a Unique Index or Business Key.
When no access constraints are defined for a resource, users/groups receive default "allow": ["*"] access.

Access Evaluation Process

The system determines effective permissions through a multi-step evaluation process at runtime:

Identify the user

Identify the user and their group memberships.

Resolve role assignments

Resolve all relevant role assignments — both group-level and user-level — at the Application Level.

Collect permissions

Determine all permissions from the assigned roles.

Apply highest scope

Apply the highest permission scope when conflicts exist between roles.

Apply constraints

Optionally filter results by tag, sensitivity, or ownership constraints.

​Overview

​Core Principles

​Key Entities

​Access

​Members

​Member Fields

​Adding a Member

​Groups

​Group Fields

​Group vs. Direct Assignment

​Roles

​Standard Roles

​Role Definitions

​Custom Roles

​Permission Sets

​Reading the Matrix

​Default Permission Set Coverage

​Permission Set Matrix

​Permission Type Reference

​Access Evaluation Logic

​Assignment Structure

​Key Rules

​Assignment Examples

​Database Schema Reference

​Schema Components

​Assumptions

​Access Evaluation Process

Overview

Core Principles

Key Entities

Access

Members

Member Fields

Adding a Member

Groups

Group Fields

Group vs. Direct Assignment

Roles

Standard Roles

Role Definitions

Custom Roles

Permission Sets

Reading the Matrix

Default Permission Set Coverage

Permission Set Matrix

Permission Type Reference

Access Evaluation Logic

Assignment Structure

Key Rules

Assignment Examples

Database Schema Reference

Schema Components

Assumptions

Access Evaluation Process