Setting DevOps Dashboard Permissions

Setting DevOps Dashboard Permissions

As of version 5.3, Curity Identity Server provides a DevOps Dashboard. The Dashboard offers self-service capabilities for developers and operations teams, allowing them to manage OAuth configurations, monitor behavior, and respond to triggered alarms. Curity Identity Server does not enable the DevOps Dashboard by default, and it requires a license to use.

You can define what users and groups can view the DevOps Dashboard, and fine-tune the settings, so teams can only access information and configurations relevant to them.

In this article, we'll discover how to enable and configure permissions for the DevOps Dashboard.

Enable the DevOps Dashboard

Navigate to System -> Admin Service and make sure RESTCONF API is enabled. Then click Enable OAuth and DevOps Dashboard and choose a Token Service Profile. From that profile, choose one or more clients that can issue access tokens that allow access to the RESTCONF API and the DevOps Dashboard. From here, also Enable DevOps Dashboard and choose the Authenticators that can be used to authenticate a user when logging in to the DevOps Dashboard.

In this article we will build on the Getting Started guides and will use the username-password authenticator.

DevOps Dashboard Client

When the DevOps Dashboard is enabled, a dedicated client named devops_dashboard_restconf_client is automatically created in the Token Service Profile you selected. By default this client is configured with the openid and urn:se:curity:scopes:admin:api scopes.

DevOps Dashboard Permissions

With the settings in place, at this point, we would have full access to the DevOps Dashboard and all configuration options it provides. However, a more common scenario is that the DevOps Dashboard is further limited based on the user's responsibilities. To achieve this, we can set permissions for groups of users and control what they can see and configure using the Dashboard.

Navigate to the DevOps configuration page to configure permissions, System -> Administrators -> DevOps.

Configure DevOps Dashboard Permissions

Click Configure Permissions. If groups are already configured within the system, they will be available on the drop-down list. If not, we can create new groups.

The group(s) we create here will be mapped against a groups claim in the user's access token. With this approach, we can map something like a group membership in LDAP/AD to a groups claim, and with that, provide different permissions in the DevOps Dashboard to various groups from LDAP/AD. We can achieve the same approach with basically any authenticator the DevOps Dashboard is configured to use as long as the groups claim is present in the token issued to the user.

When configuring a group and its permissions for the first time, a wizard will guide you through the process. This helps you review and get a better sense of all the permissions for that group (devops1 in the screenshot).

DevOps Permissions

The settings we can control are:

  • Access to view Alarms.
  • Access to OAuth clients, and with that, control over what clients the group can access. You can control this by configuring all or only selected OAuth Profiles and all or selected clients.
  • If they can change the scope settings.
  • If clients with access can make changes.

The DevOps Dashboard

With the permissions configured, a user assigned to the group devops1 will see the following after logging in:

The menu on the left shows the different configurations exposed by the DevOps Dashboard. The views for each are essentially identical to what the full admin UI provides.

Modifying settings when prohibited

Although the user can see all of the scopes, if the configuration prevents them from modifying them, an error message will be displayed when trying to save any changes. Deny changes


With permissions configured in the DevOps Dashboard, teams only have access to information relevant to them and will not be able to interfere with other configurations of the OAuth server. Therefore, operations teams can view and act on alarms triggered in the system without having access to the full OAuth server configuration. With a self-service approach, users can manage configurations to get their work done faster.