👨‍💼Role-based Access (RBAC) and Tenant Access Logs

12/2024

Overview

The Cisco Identity Intelligence security platform provides several different roles with different permissions for access your CII tenant dashboard.

  • Full administrator (admin)

  • Read only

  • Help desk

  • Application manager

  • User manager

  • Security analysi

This article describes the permissions associated with each role and how to configure your IDP or IAM platform to support each role.

The article also discusses how to use the Tenant Access page to review recent administrator or user access to the CII console.

Roles and Permissions

Full Administrator

As the name suggests, full administrator (admin) can take all actions within your CII tenant, including:

  • adding or deleting integrations

  • changing tenant settings

  • configuring Checks settings

  • excluding users from Checks

  • configuring notification targets like Slack or Teams channels

  • opening tickets with ITSM platforms like ServiceNOW or Jira

  • all actions available within the Remediation Actions article

Read-only Role

Read-only CII users can view all of the data and users within the console, but cannot make any changes to the configuration of the platform or take any actions related to User objects, such as opening tickets or sending notifications.

Help Desk role

Help desk users can view all data and perform a subset of actions within the console. These actions include user-related actions, such as:

  • Opening tickets for investigation or remediation

  • Resetting a users MFA

  • Modifying specific user attributes, such as User Type

  • Logging a user out of active sessions in one or more IDPs

  • Refreshing user events for troubleshooting

Application Manager

The Application manager role's primary purpose is for creating and maintaining the various integrations available within CII. These include IdP systems like Duo, Entra ID, Okta, Google, etc., as well as other notification systems like Webex, Teams, and Slack.

The Application Manager role can:

  • perform any action on the Integrations page

  • only access the Integrations and Profile pages

  • view System Logs for analyzing integration logs

User Manager

The User Manager role:

  • can perform any operation on Users

  • cannot triage failed checks ( mark as suspicious/normal, exclude user from check)

  • cannot access Integrations or Dashboard page

  • can view System Logs for purposes of analyzing end user logs

Security Analyst Role

The Security Analyst role

  • can perform operations on the Users table page and individual user objects page - create and modify Saved filters, create tickets, trigger End User Refresh, trigger remediation actions

  • can perform operations on Checks – modify check settings and check tags, provide feedback, enable/disable checks, triage failed checks for users, (e.g. exclude/include in checks, mark as suspicious/normal)

  • can update the protected population

  • cannot access Integrations page

  • can view System Logs for analyzing end user logs

The full list of Remediation Actions and their associated details is available in this article.

Read-only role
Help desk role
Admin role

Refresh user data

All read-only actions

All actions

Mark as suspicious

Open ticket (to ITSM platform)

Mark as normal behavior

Remediation actions

Failed Checks triage actions (mark as suspicious/normal, exclude from check)

Send notification (to user, manager, or notification channel in Teams, Slack)

Send push notification (Duo, Okta)

Configuring IDP Groups to Support RBAC Roles

CII uses group membership within your IDP or IAM platform that is used for SSO into the Dashboard, such as Duo, Okta or Entra ID. Specifically, the groups must be returned as part of the OIDC token or the SAML assertion.

Also, because users may have a long list of group memberships in your IDP, we require that the token returned by your SSO solution contain less than 40 groups.

We suggest that the group name starts with or contains CII so that the groups can be filtered when returned by the IDP.

The methods to configure this functionality vary by IDP platform. For more information for each, please see the corresponding article for your SSO platform connected to Oort -

Confirming Group Membership Token Info

To confirm that the desired groups are being passed in the OIDC or SAML token after the groups have been created and populated and the SSO configuration is complete, do the following -

  1. Log into the Oort console with a user that is a member of one of the created groups, e.g CII admin

  2. Under the admin user account name, select Profile

Mapping Groups to Roles in the Oort Console

After the groups have been created and populated and the SSO configuration is complete, an Oort full admin can create the role -> group mapping in the Oort console.

Default Dashboard User Role

Within the Oort staging environment which primarily hosts evaluation and test environments, users of the Oort Dashboard are presumed to be full admins be default, unless the groups above are in use and controlling access.

In production Oort environments, the default role assignment can be switched to another role, such as read-only or help desk role. Then Oort users will only be full admins if members of the Oort admin group defined in your IAM solution.

Viewing Recent Dashboard Users and Roles

Within the Oort dashboard, you can view your current role, as well as the users of the platform and their associated roles.

  1. Login to your Oort Dashboard

  2. Your current role will be displayed under your profile name in the top right corner Note - if an account is a member of multiple groups associated with roles in the Oort console, such as both full admin and read-only admin, then the least privilege group and role with take precedence.

  3. Under your profile menu, there will be an option for Tenant Access

PreviousTenant SettingsNextSystems Logs

Last updated