Authorizations in ADOC
Overview of RBAC and RBAM
What is Role-Based Access Control (RBAC)?
RBAC is a method of managing user permissions based on roles assigned within an organization. Each role has a predefined set of permissions that apply across the system.
What is Resource-Based Access Management (RBAM)?
RBAM builds on RBAC by introducing domains and resource groups, allowing enterprises to restrict access to specific assets, such as data sources, reports, policies, and dashboards.
RBAM allows administrators to:
- Define logical zones (domains) that hold certain resources.
- Assign users (via groups) to these domains.
- Control not only what users may do but also which resources they can use.
RBAM: Extending RBAC Capabilities
RBAM is designed to complement RBAC by providing an additional layer of resource-specific control, The table highlights how RBAM enhances standard RBAC capabilities.
| Feature | RBAC (Baseline) | RBAM (Additional Layer) |
|---|---|---|
| Access Scope | System-wide | Resource-specific within domains |
| Resource Visibility | Users see all system resources permitted by their roles | Users only see resources explicitly assigned to domains |
| Granular Control | Controls user actions in the system level | Extends control to resource visibility and domain-specific permissions |
| Administration | Centralized | Delegated administration via domains and resource groups. |
| Compliance | Provides basic control suitable for general compliance | Stronger data segregation for regulations (GDPR, HIPAA, NIST) |
Why Do Enterprises Need RBAM?
- Enhanced Security – Restrict access to only necessary resources.
- Granular Control – Assign permissions at domain/resource group level.
- Regulatory Compliance – Supports strict data access regulations.
- Improved Scalability – Manages access efficiently across multiple teams.
While RBAC assigns users to roles granting permissions that determine their access to application-wide features, RBAM roles provide a more granular control by granting permissions to access features on specific resources. Together, they ensure that users have appropriate access at both the application and resource levels, enhancing security and operational efficiency.
Understanding RBAC in ADOC
RBAC Roles, Permissions, and Hierarchy
RBAC ensures controlled access to ADOC features by assigning users to specific roles. Roles determine the level of access granted across the system.
RBAC Components in ADOC
Tenant Roles: Define access across the entire application.
- System-Defined Roles: Predefined roles (e.g., Admin, Owner, Viewer).
- User-Defined Roles: Custom roles created based on business needs.
Tenant Admin : Full platform access that bypasses RBAM domain scoping. Treat with the same caution as root in Linux; reserve for break‑glass scenarios.
RBAC Role-Permission Mapping
| Role | API Keys | User Management | Data Observability | Compute |
|---|---|---|---|---|
| Owner | Create, Modify, View | Full access | Full access | Full access |
| Admin | Create, Modify, View | Full access | Limited access | Full access |
| Editor | Limited access | Modify, View | Modify, View | |
| Viewer | View only | View only |
How to Configure RBAC Roles in ADOC
- Navigate to Settings → User Management → Tenant Roles.
- Select an existing role or click Create New Role.
- Define role permissions for various features (e.g., API Keys, Compute, Data Observability).
- Assign users or user groups to the role.
- Save and apply changes to ensure permissions take effect.
For more information, see User Management, Resource Groups and Domain Management.
Common Misconfigurations & Fixes
| Misconfiguration | Issue | Solution |
|---|---|---|
| Assigning a role without necessary permissions | User cannot access certain features | Review required permissions and update role configuration |
| Overlapping permissions across multiple roles | Users may have conflicting permissions | Use the Access Visualizer to visualize how RBAC and RBAM roles intersect. |
| Assigning RBAM domain roles without corresponding RBAC permissions | RBAM permissions do not work | Ensure users have appropriate RBAC tenant roles before assigning RBAM roles |
Introduction to RBAM in ADOC
Core RBAM Components
Domain:
A domain is a logical or virtual zone defined by the resources it contains. Domains typically align with functional areas within an enterprise, such as Sales, Marketing, or Operations. Domains are like "mini-tenants" where you can group specific assets and reports together.
Domains should be considered as a bridge between the functional area documented in the business requirements and the technical definition of the Resource Groups. For example, the domain may align to common data products or domains made available across an organization such as Customer or Product. It could also align to a business unit's data that is not to be shared across the organization such as Audit or Finance.
Each domain contains:
- Resource Groups: Bundles of assets and reports specific to the domain.
- Users and Groups: Individuals or teams who require access to the domain's resources.
- Domain Administrators: Users with administrative rights within the domain.
Resource Groups
Resource Groups are collections or resources that can be assigned to a domain. They are of two types:
- Asset Groups : Collection of assets like tables and data sources.
- Report Groups : Collection of reports relevant to the domain.
Resource Groups serve as the basic building component for RBAM, acting as the link between the domain and the assets under management.
Keeping these clear and consistent is critical to creating a workable implementation. Unless otherwise required, consider connecting a Resource Group to a Data Source. This will provide a clear and logical connection between domains and the resources they guard.
However, there will be situations in which finer or coarser groupings are required or preferred. For example, if a data product is established to incorporate assets from multiple data sources, it may be simpler to define the Resource Group to include them.
Consider these broad rules of thumb:
- Define resource groups with the coarsest grain feasible up to a data source.
- Limit an asset to a single resource group wherever possible.
- Record any departures from the design concepts.
- Use the Access Visualizer to understand the outcomes of your design.
A domain without resource groups is effectively empty. Only after you add resource groups to a domain do the associated resources become visible to the users in that domain.
Tenant Roles vs. Domain Roles
- Tenant Roles: System-wide roles that are not domain-specific (e.g., managing global features such as compute or user administration).
- Domain Roles: Context-specific roles that apply within the boundaries of a single domain. Domain roles can only be assigned to user groups and must be associated with a particular domain.
A set of system-defined Domain Roles are provided. Review these in depth and only create new ones if absolutely necessary. Remember, these act in conjunction with the Tenant Roles which define platform level permissions. Domain Roles grant permissions to perform typical tasks on the assets, reports or domains assigned to a user.
User Groups
While user groups in the platform can be assigned both tenant roles and domain roles, consider creating separate groups for the assignment of RBAM permissions. Since the assignment of a domain to a User Group includes one set of domain roles, if a domain needs multiple permission levels create additional user groups and assign each the appropriate combination of Domain Roles.
A combinatorial expansion of User Groups might be required if RBAC and RBAM permissions are combined, hence the recommendation to keep them separate.
Previously, policy actions (view, create, modify, execute) were managed via tenant RBAC roles. From v4.2 onward, these permissions are managed using domain-level roles, providing better granularity.
Policy Permission Changes in v4.2
| Action | Old Permissions | New Permissions |
|---|---|---|
| View Policy | view:asset | view:policy + view:asset |
| Modify Policy | view:asset | modify:policy + view:asset |
| Create Policy | view:asset | create:policy + view:asset |
| Execute Policy | view:asset | execute:policy + view:asset |
Note: Assets remain the anchor resource. All policy actions require view:asset.
Implementation Principles
When starting to design an RBAM implementation, it is useful to start with some guiding principles. These are intended to be starting points that promote consistency and simplicity.
The principles mentioned here should not be considered rigid rules. Deviation from the guidelines should be considered as long as they are justified and documented.
Business Requirements
Understanding and establishing the business requirement is an important starting point for any RBAM implementation plan. This would normally start with a high-level definition of the business area, the user population, and the data scope.
Example: The business area might be Supplier Information Management, the user population might span Vendor Management and individuals involved in procurement in other departments, and the scope of the data assets might be the databases and reports under management of that department. Once defined, a review of the access needed for sets of assets in that scope should be made with particular attention to assets that may need to be accessible or inaccessible to groups within the user population.
Least Privilege Model
The Least Privilege model is intended to deliver only the privileges to a user required to complete the users task. While this extends to both RBAC as well as RBAM, with respect to RBAM this means assigning users only the domains absolutely necessary with the appropriate Domain Roles.
This may lead to more complexity in designing Resource Groups, Domains and Domain roles but this should be balanced with the other Implementation Principles.
Minimize Number of RBAM Objects
RBAM introduces a number of new concepts such as Resource Groups, Domain Management, Access Visualizer and Domain Roles. The recommendation is to start with the minimum number of these objects to satisfy the business requirement.
While the urge may be to define Resource Groups very granularly from the start, this may lead to too much management overhead and complexity when defining the relationships between these objects. Instead, start with the coarsest grain possible to meet the requirements. Finer grained grouping can be added later to refine the model.
Example: If all users will have access (any access) to all or none of the objects in a data source, then align a Resource Group to a data source. If partial access is needed, then additional analysis is needed to decide how to align the Resource Group most efficiently. Unless required, try to keep an asset (data source, table, report, etc.) in a single Resource Group.
RBAM Workflow in ADOC
The following steps outline a common approach to implementing RBAM. However, depending on your organization’s structure or needs, the order may vary.
For example, some teams prefer to begin with defining Resource Groups before creating Domains, as this helps establish a clear understanding of what needs to be grouped and controlled.
- Create Domains – Define logical groupings of resources.
- Create Resource Groups – Associate assets with domains.
- Assign Users & Roles – Define user permissions within domains.
- Test & Audit – Verify proper access control implementation. Also see, Access Visualizer
Implementing RBAM: Step-by-Step Guide
Step 1 : Plan RBAM Implementation
- Define business units that require access control.
- Identify domains and resource groups based on organizational structure.
- Avoid role explosion by keeping roles structured and limited.
Step 2: Creating Domains
- Navigate to Settings → Domain Management → Domains.
- Click Create Domain, define name, description, and resource groups.
- Assign user groups with appropriate domain roles.
Step 3: Assigning Resource Groups
Best Practices:
- Align group with data source
- Avoid overlapping groups
- Use naming conventions
Example:
- Finance Domain > Finance ARG + Finance RRG
- Marketing Domain > Marketing Reports Only
Step 4: Assigning Users & Permissions
| Domain Role | Permissions |
|---|---|
| Resource Viewer | view:asset, view:policy |
| Resource Editor | modify:asset, modify:policy |
| Resource Owner | create:asset, create:policy |
| Domain Manager | All domain permissions |
All users must have required tenant roles for RBAM roles to take effect.
Step 5: Testing & Auditing
- Use test accounts to verify access
- Review access logs and use the Access Visualizer to visually inspect how users, groups, and roles are linked across domains and resources.
- Periodically audit roles for cleanup
Best Practices for RBAC & RBAM (Across Industries)
| Industry | Best Practices |
|---|---|
| Finance |
|
| Healthcare |
|
| Government |
|
| Tech / Cloud |
|
Compliance & Security Considerations
| Compliance Standard | RBAM Contribution |
|---|---|
| GDPR | Data minimization via domain scoping |
| HIPAA | Patient data isolation via domains |
| PCI-DSS | Role-based visibility of payment resources |
| SOX | Traceability in audit logs |
| NIST 800-53 | Granular access controls by domain |
Frequently Asked Questions (FAQs)
Q1. Can a user belong to multiple domains?
Yes. Each domain assignment is independent.
Q2. What happens if a user has both RBAC and RBAM roles?
RBAM domain roles only work if the corresponding RBAC permissions (e.g., view:asset) are assigned.
Q3. Can one asset belong to multiple resource groups?
Technically yes, but this is discouraged due to management complexity.
Q4. What’s the RBAM migration strategy?
Tenant roles are preserved. Resources are moved into default domains, and access is reconfigured gradually.
Q5. Can RBAM policies be automated?
Partially. You can automate user and group provisioning via SCIM, and RBAM configurations like domains, resource groups, and role mappings can be managed via APIs. As of ADOC v4.2, policy-related permissions are now part of domain roles, enabling better granularity — but direct automation of policy-level access is limited and depends on domain-resource alignment.
Q6. What changed in ADOC v4.2?
Policies now respect domain roles for permissions instead of tenant roles. See New in ADOC 4.2 - RBAM for policies for more detail.
Q7. How can I quickly debug why a user can’t access a resource? Use the Access Visualizer to trace user-to-role mappings and domain-level permissions. It helps identify missing roles, misconfigurations, or visibility issues.