Support Additive Role Permissions for Users Assigned Multiple Roles

Problem Statement

Instana currently evaluates multiple assigned roles using a restrictive (least-permissive) access model. When a user is assigned multiple roles, permissions do not combine into a cumulative set of privileges. Instead, restrictive permissions can effectively limit access even when another assigned role grants additional capabilities.

This approach creates scalability and administrative challenges for organizations that use role-based access control at scale, especially when roles are mapped to departments, teams, or job functions. 

Business Impact

Organizations frequently have users who require a combination of permissions spanning multiple functional roles.

Examples:

• A user belongs to a department role that grants standard application access.
• The same user also performs agent administration tasks.
• Another user may require billing access in addition to operational access.
• Some users temporarily perform responsibilities outside their primary function.

Because roles are not additive, administrators must create separate custom roles for every unique permission combination. This leads to:

• Role proliferation.
• More complex role naming conventions.
• Higher administrative overhead.
• Increased risk of misconfiguration.
• Reduced scalability of RBAC design. 

As the number of teams and permission combinations grows, the number of required roles grows exponentially rather than remaining manageable.

Proposed Enhancement

Introduce a mechanism that allows permissions from multiple assigned roles to be combined additively.

Possible implementation options:

Option 1 (Preferred)

Allow administrators to designate a role as "Additive" or "Cumulative."

When a user receives multiple roles:

• Permissions granted by additive roles are merged into the user's effective permissions.
• Existing restrictive behavior remains available for organizations that prefer the current model.

Option 2

Add a tenant-level configuration option:

• Restrictive Role Evaluation (Current Behavior)
• Additive Role Evaluation

Option 3

Provide a per-role permission conflict strategy such as:

• Restrictive
• Additive
• Explicit Override

Current Behavior Example

Role A - website access=YES , Mobile App Access=NO

Role B - website access=NO , Mobile App Access=YES

Role A+B applied to user, results in Access is restricted and permissions do not combine as desired.

Desired behavior:

Effective permissions: Website Access = Yes, Mobile App Access = Yes.

Benefits

• Significantly reduces RBAC complexity.
• Eliminates the need to create unique roles for every permission permutation.
• Improves scalability for large enterprises.
• Simplifies role administration and auditing.
• Aligns with common enterprise RBAC expectations found in other platforms.
• Provides flexibility while preserving the current restrictive model for customers that prefer it.