About Permissions

Learn about the permissions that grant access to and control over different areas of the Oracle Communications Unified Assurance user interface (UI).

About Permissions

To control access to Unified Assurance UIs, you create roles, which are collections of permissions and actions. Permissions authorize actions on REST API endpoints, which correspond to elements of the user interface.

After creating roles, you assign roles to user groups, then add individual users to groups. The users inherit the permissions from the role assigned to their user group. To create read-only users, assign them to a group associated with a role that has only the read action enabled for permissions.

In addition to assigning permissions at the role level, you can set restrictions at the user group level for certain resources, such as device groups, filter groups, and event menus. Permissions control access to APIs and UI areas, and restrictive properties control which subset of the data appears in those API responses and UIs. See Authentication Options and Adding User Accounts for more information about roles, user groups, users, and restrictive user group properties.

You can create many different combinations of permissions in different roles to grant access to different areas and interfaces of the UI and API resources. When creating roles, you can clone a less restrictive role, such as Operator, and remove permissions until only the necessary permissions remain, or you can create a new role and grant only the necessary permissions.

In the Roles UI, the permissions are organized by package to help you identify the general area of the UI that they grant access to. For example, permissions under the AAA package grant access to the UIs accessible in the Configuration menu under AAA.

Packages with Navigation in the name control which options appear in the main navigation menu. For example, granting the Devices permission in the deviceNavigation package adds the Devices option to the main navigation menu. Granting the permissions in the navigation package adds the Configuration menu and the Bookmarks option to the main navigation menu.

Even if you plan to restrict users to certain areas of the UI, their role will need permissions from multiple packages. For example, to see meaningful data on metrics dashboards, a role would need multiple permissions in dashboard and metric packages, and because metrics are tied to devices, it would also need a variety of permissions in the device package. See Permissions for Sample Roles for more detailed examples.

See Permissions Reference for reference information about all permissions, and a list of permissions that grant access to each Unified Assurance UI.

Note:

Although this topic focuses on how permissions work in the UI, because the data in the UI comes from the REST API, permissions control access to the corresponding resources through the API. The roles of users making API calls must have the correct permissions to perform operations on resources.

About Permissions Actions

You can enable or disable the following standard CRUD actions for permissions:

Some Unified Assurance permissions also include the execute action. This lets you use the REST API and UI to initiate background processes, including:

In the API, execute actions correspond to GET requests when the input is simple, such as starting a job based on its ID, or POST requests when the input is complex, such as checking the syntax for a CAPE node or running a database query.

Permissions for All Roles

For basic UI functionality, all roles need at least read access to the permissions in the core package.

Although you can specify some settings like locale, time zone, and theme at the user or user group level, granting access to these permissions at the role level allows users and user groups to use the system-wide defaults.

To provide enhanced UI functionality, you can optionally:

Permissions for Sample Roles

The sample roles described in this section provide different levels of monitoring access. You can adapt them for your needs by adding additional actions and permissions.

Creating an Event List Viewer Role

This role allows users to perform basic event list monitoring. It grants access to the event list and event tools.

To create the event list viewer role:

  1. Create a new role for viewing the event list.

  2. In the core package, enable the read action for all of the permissions.

    This enables basic UI functionality.

  3. In the eventNavigation package, enable the read action for the Events permission.

    This adds the Events navigation option to the main navigation menu, granting access to the events landing page with a list of filter groups and filters.

    Later, you can restrict which filters appear for users by setting the RestrictiveFilterGroupID for user groups.

  4. In the event package, enable the read action for the following permissions:

    1. To grant access to items and menus in the event list:

      • DisplayConversions: This is optional, but recommended. It shows a more readable form of some data that has been converted from its raw form in the database. For example, there is a default conversion for event severity to show a word rather than an integer. Without this permission, the integer would appear.

      • Displays: Shows items in the Display menu on the event list and sets the display when you select an event from the list.

        Without this permission, you cannot select a different display, and you cannot see details for most events.

      • Events: Shows events.

        Without this permission, you cannot see any events.

      • FilterGroups: Shows items in the Filter Groups menu on the event list.

        Without this permission, you cannot change the currently selected filter group in the event list.

      • Filters: Shows items in the Filter menu on the event list.

        Without this permission, you cannot change the currently selected filter in the event list.

    2. To enable context menus and tools for events:

      • Menus: Enables Unified Assurance context menus for events.

        Without this permission, the default browser context menu appears when you right-click an event rather than the Unified Assurance event context menu.

      • Tools: Lets you use the tools in Unified Assurance context menus. Also enable the execute action to use hybrid tools.

        Later, you can restrict which event tools appear for users by setting the RestrictiveEventMenuID for user groups.

      Without these permissions, tools will appear in context menus, but selecting them will not have the expected result.

  5. In the device package, enable the read action for the following permissions:

    • DeviceViews

    • Devices

    These enable device and metric related event tools, such as Device Info and View Metric. Without these permissions, the tools will appear in context menus, but selecting them will not have the expected result.

  6. In the metric package, enable the read action for the following permissions:

    • Metric

    • PerformanceData

    These enable metric related event tools, such as View Metric. Without these permissions, the tools will appear in context menus, but selecting them will not have the expected result.

  7. Save the role and create corresponding user groups and users, setting their restrictive properties and default displays as needed.

Creating an Event List and Diagram Viewer Role

This role allows users to perform basic event list monitoring and also view diagrams.

To create the event list and diagram viewer role:

  1. Do one of the following:

  2. In the diagramNavigation package, enable the read action for the Diagrams permission.

    This adds the Diagrams navigation option to the main navigation menu, granting access to the diagram landing page with a list of diagram groups and diagrams.

    Later, you can restrict which diagrams appear for users by setting the RestrictiveDiagramGroupID for user groups.

  3. In the diagram package, enable the read action for the following permissions:

    • Diagrams: Lets you access diagrams.

      Without this permission, selecting a diagram from the list does nothing.

    • Menus: Enables Unified Assurance context menus for diagrams.

      Without this permission, if a widget is configured with a menu, no tools appear when you right-click the widget, just the words No Actions Available.

      Some of the default diagram tools require additional permissions. For example, the Network Details and Device Health tools require access to dashboards and their related panels, and the Metrics tool requires the AllMetricsOverview permission in the metric package.

      Later, you can restrict which tools appear for users by setting the RestrictiveDiagramMenuID for user groups.

    • Widgets: Lets the widgets on diagrams work.

      Without this permission, widgets on diagrams are static images rather than being dynamically updated, providing links, or playing sounds.

      Event and metric widgets also require related permissions to enable them to show meaningful data.

  4. Save the role and create corresponding user groups and users, setting their restrictive properties and default displays as needed.

Creating an Event List, Diagram, and Dashboard Viewer Role

This role allows users to view the event list, diagrams, and dashboards for detailed monitoring. Because dashboards can contain a wide range of data, this role requires a permissions from a greater variety of packages. It grants access to most Unified Assurance UIs, other than those used for analytics and configuration.

To create the event list, diagram, and dashboard viewer role:

  1. Do one of the following:

  2. In the dashboardNavigation package, enable the read action for the Dashboards permission.

    This adds the Dashboards navigation option to the main navigation menu, granting access to the dashboard landing page with a list of dashboards and dashboard groups.

    Later, you can restrict which dashboards appear for users by setting the RestrictiveDashboardGroupID for user groups.

  3. In the deviceNavigation package, enable the read action for the Devices permission.

    This adds the Devices navigation option to the main navigation menu, granting access to the devices landing page.

    Later, you can restrict which devices appear for users by setting the RestrictiveDeviceGroupID for user groups.

  4. In the config package, enable the read action for the ViewConfigs permission.

    This lets you see device configuration information on View Config panels on dashboards.

  5. In the dashboard package, enable the read action for the Dashboards permission.

    This lets you access dashboards. Without it, selecting a dashboard other than an adhoc dashboard will result in an error.

  6. In the database package, enable the read action for the following permissions:

    • Queries

    • Databases

    Also enable the execute action for the QueryTools permission.

    These let you see information on Database Grid panels on dashboards.

  7. In the device package, enable the read action for the following permissions:

    • Groups

    • Zones

    • MetaTypes

    • MetaData

    These let you see device information on dashboards and in the device list.

  8. In the event package, enable the read action for the ForensicViews permission.

    This lets you see forensic event lists on dashboards.

  9. In the file package, enable the read action for the Files permission.

    This lets you see images on dashboards.

  10. In the graph package, enable the read action for all of the permissions.

    This lets you see graphs on dashboards.

  11. In the link package, enable the read action for the Links permission.

    This lets you select links in Dynamic Input panels in dashboards.

  12. In the metric package, enable the read action for the following permissions:

    • AllMetricsOverview

    • DeviceGroupAvailability

    • MetricGroups

    • Metrics

    • NetworkTraffic

    • PerformanceData

    • RetentionPolicies

    • Types

    • TopNData

    These let you view metric information on dashboards.

  13. In the notification package, enable the read action for the following permissions:

    • Profiles

    • Templates

    These let you view notification profiles and templates.

  14. In the SLM package, enable the read action for the following permissions:

    • ServiceFilters

    • ServiceMetrics

    • ServiceViews

    These let you see information about SLM services on dashboards.

  15. In the topology package, enable the read action for the following permissions:

    • Layouts

    • Menus

    • NetworkDetails

    These let you see network topology information on dashboards.

  16. Save the role and create corresponding user groups and users, setting their restrictive properties and default displays as needed.

Troubleshooting Missing Permissions

You may encounter permissions errors in the UI as pop-up notifications, in the error bar at the bottom of a table, and on the Network tab of your browser's developer tools. These messages use the following format:

Permission required: <package>::<permission>::<action>

For example, an error indicating that you need the read action enabled for the AllMetricsOverview permission in the metric package might appear in the following ways:

You may also encounter errors that advise you to check configurations or restrictive access. These can indicate a permissions error. You can look in the Network tab of your browser's developer tools to identify the missing permission. For example, the following error indicates a problem with the dashboard permissions:

Unable to load Dashboard (Basic Services Dashboard)
Please check the dashboard configuration or restrictive access

Opening the browser developer tools and reviewing the GET request for the Basic Services Dashboard reveals a response with the following error:

{
    "success": false,
    "message": "Permission required: dashboard::Dashboards::read",
    "data": []
}

This error indicates that the read action for the Dashboards permission in the dashboard package is missing from the user's role.

Managing Permissions with the REST API

In addition to using the UI to view and manage permissions, you can also use the REST API. See the endpoints under AAA in REST API for Unified Assurance Core.

For example, roles with the read action for the AAA:Permissions and AAA:Roles permissions can:

Roles with create, update, and delete actions enabled for the AAA permissions can also use REST requests to make requests to set, update, and delete permissions for roles.