Role-Based Access Control

Role-Based Access Control (RBACClosed Role-Based Access Control) determines what features and content users can access throughout the applicationClosed An entity type representing software applications deployed in the customer environment that are monitored for performance and anomalies.. Roles are assigned through the User Management page. RBAC is a platform-wide system. The same permission model applies across the product wherever roles are enforced, from scheduling and automation to the Packet Capture Module Web UI, Riverbed Workspaces, data forensics, and tenant administration.

You can assign several predefined roles to users on the platform. That approach gives more precise control over what each user can or cannot do in each area of the product.

Every predefined role name, description, and scope is documented in Riverbed Console Built-in Roles. The main table includes an Area column that groups each role with the part of the product it governs (about ten values, such as Scheduling, Automation, Integrations, and PCM). That column is an organizing label in the reference.

When a user signs in, the product evaluates all roles assigned to that account and adjusts the UIClosed User Interface. The visual components and controls that users interact with to access features and manage the system. so that the user sees the actions and content their roles allow.

How RBAC controls UI content visibility

Each role defines what the user can do in its area. Together, the assigned roles determine what actions the user can perform and what content is visible in the user interfaceClosed An entity type representing network interfaces on devices that are monitored for performance metrics and anomalies..

What roles control

Roles control different aspects of the interface:

  • UI elements: Which buttons, menus, and controls appear. Actions are enabled or disabled based on whether the user's roles allow that action.

  • Data access: Which information is visible to the user. Search and similar features require the appropriate role for that area.

  • Feature availability: Page tabs and sections are shown or hidden based on whether the user's roles allow access to that area. If the user cannot access a section, it may be hidden. Pages the user cannot access at all show an "Access Denied" message.

  • Settings access: Which configuration options can be viewed or changed. View-only versus edit behavior follows the same pattern.

How access is evaluated

The product checks access at multiple levels:

  • Page-level access: When the user opens a page, the product checks whether the user's roles allow that page. If not, the user sees an "Access Denied" dialog.

  • Tab-level visibility: On pages with multiple tabs, each tab is shown only if the user's roles allow that part of the page.

  • Action-level control: Individual buttons and actions are enabled or disabled based on whether the user's roles allow that action.

Role naming conventions

For many feature areas, role names follow the same pattern:

  • Contributor: Full control over resources in that area, but cannot manage who else has access. The user can create, change, or remove items, but cannot grant roles or access to others.

  • Operator: View what exists in that area and run or execute supported actions. For example, an Automation Operator can open and run runbooks but cannot edit their definitions.

  • Reader: View everything in that area that the role covers. Change nothing.

User Access Administrator is separate from that pattern. It is only for managing role assignments (who can access what). It does not grant access to product resources or features outside user management. Use it when accounts and role assignments should be managed by one group of administrators, while other roles govern access to Automations, Workspaces, and the rest of the product.

Not every area uses all three suffixes. Some roles use a specific name (for example, IQClosed Product abbreviation for the AI-Ops platform that provides intelligent operations and automation capabilities. Ops Operator or Tenant Administrator) where that better describes the job.

Predefined roles

Administrators assign one or more predefined roles to each account. Many roles line up with shared capabilities such as scheduling, automation, integrations, audit, user administration, tenant settings, and IQ Ops. Others apply only to specific experiences, such as the Packet Capture Module Web UI, Riverbed Workspaces, or data forensics workflows. Assign the combination that matches each job. The product always evaluates the full set of roles on the account together.

This topic explains how RBAC works in the product. It does not repeat the full role catalog. For every built-in role, its description, and its Area value, see Riverbed Console Built-in Roles. That topic also includes feature-by-role tables for PCM and for Workspaces and data forensics.

Note: You can assign multiple user roles to a single user. For example, a single user can have both a platform role and a PCM role.

For a UI-area summary that relates read, write, and administrative access to major parts of the product, see User Role Definitions.