DevOps Dashboard User Administration

The DevOps Dashboard concepts article explains the role of the DevOps dashboard. It enables groups of employees to administer the identity and access management (IAM) system, with different permissions. The dashboard also enables you to list, create and edit customer users, in a visual and productive manner. This tutorial shows how to get up and running, and explains the authorization concepts.

The Curity Identity Server does not enable the DevOps Dashboard by default. To do so, first ensure that you have a valid license file, such a trial license with access to the dashboard feature and at least 3 user groups. This tutorial will start from the default Docker based setup and manage customer users in a SQL data source.

Example Deployment

The GitHub repository at the top of this page can be used to quickly run a working setup. Clone the repo, then copy the license.json file to the root folder and run the deployment script:

./deploy.sh

Next, login to the Admin UI with the following details, to view configuration settings. The default deployment of the Curity Identity Server uses self-signed certificates, so first ignore the browser warning and proceed to the Admin UI when prompted.

• URL: https://localhost:6749/admin
• Admin UI credentials: admin / Password1

In the example deployment there are two employee groups, summarized below. When required, the DevOps dashboard and its authorization can scale to many teams in a large organization.

You can login to the DevOps dashboard with either of these details:

• URL: https://localhost:6749/admin/dashboard
• DevOps user: johndoe
• Developer user: janedoe

After login, the devops user has full access to customer user details:

This tutorial will walk through how the example deployment was configured. You can then apply similar configuration to your own system.

Initial Setup

First an empty Docker based deployment was run, as explained in Install using Docker. Next, a username authenticator was created, for employees, as explained in Configure an Authenticator:

In the Admin UI, navigate to System -> Admin Service. The RESTCONF API is required, and also the DevOps Dashboard option. When the dashboard option is selected, the following prompt is presented, where the token service and authenticator are configured:

Both the Admin UI and runtime node must use the same HTTP or HTTPS scheme. Under System -> Deployment, the service role in the example setup uses HTTPS and a keystore:

Initial Dashboard Login

A new entry is then provided in the top level menu, to allow dashboard logins:

This results in two admin URLs for the Curity Identity Server:

When you select a dashboard login, an OAuth flow is run, and it is possible to authenticate in many ways. A popup window is used for the login, so you must ensure that the browser allows popups for the domain of the Curity Identity Server:

When using the example deployment, login as the johndoe or janedoe test users. For a new Docker deployment, use the default admin user instead. You then get access to initial dashboard features, such as creating clients. At this point you are up and running in a basic way, but user administration is not configured yet:

Employee Groups

Employees who manage the Curity Identity Server should always use a different authenticator to your customer users. Often this will be an identity provider (IDP) from your cloud platform, such as Azure Active Directory. That system can provide some kind of employee role or group attribute. The example deployment simulates this by setting a role attribute in an authentication action, that runs after the username is submitted:

function result(context) {
    
    var attributes = context.attributeMap;

    if (attributes.subject === 'johndoe') {
        attributes.role = 'devops';
    }

    if (attributes.subject === 'janedoe') {
        attributes.role = 'developer';
    }
    
    return attributes;
}

Administrator User Types

For convenience, the Curity Identity Server provides a default admin user. This is then saved to the XML configuration during backups. It is possible to add new users that are managed in this way, and to associate groups and permissions to them, as explained in the Access Control Rules tutorial.

In many real-world setups, administrators instead originate from an external system or data source. It is important to understand the type of administrator user, since this affects how groups are used for authorization, described later in this tutorial.

Enable User Management

The users managed in the dashboard will be customer users. In the example deployment a SQL database is used, which is pre-shipped with two users, named bob and alice. These users would typically login to your web and mobile apps.

A user management profile was created, from the home screen of the Admin UI, and the dashboard authorization manager was selected. This controls access to customer user accounts.

Under the Endpoints page of the user management profile, a GraphQL endpoint is configured, since the DevOps dashboard uses this API to read and write customer user accounts:

The example setup enables credential management on the Data Sources page of the user management profile. This enables passwords to be stored for customer users, for scenarios where they sign in with a username and password:

Dashboard Groups and Permissions

Under System -> Administrators -> DevOps, three groups were created:

The admin and devops groups are granted full dashboard permissions, whereas the developers group only has access to edit OAuth clients:

Populate the Groups Claim

In the example deployment, navigate to System -> Authorization to see the configured levels of access to customer user accounts. Notice that members of the developers group have no access:

When a user logs in to the DevOps dashboard, a groups claim is issued in the access token returned to the dashboard OAuth client. This is then mapped to the above access levels.

Groups Claim Types

The two types of group claim are summarized in the following table, for the two types of administrator user:

When logging into the dashboard with the built-in admin user, the first type of group claim is used. For the example DevOps and developer users, the second type of group claim is used.

Groups Claim Evaluation

The DevOps dashboard uses a generated OAuth client named devops_dashboard_restconf_client. This uses the following scope:

openid urn:se:curity:scopes:admin:api

To make the DevOps dashboard work for the example employee users, navigate to Token Service -> Clients. In the token designer window, add a new groups claim, add it to the above scope, then drag the scope into the access token pane:

The runtime value of the groups claim is set by a subject claims provider. This provides access to the role property set in the authentication action that ran after the example deployment's username authenticator. The role is then translated to a groups claim to be issued to the access token:

OAuth Troubleshooting

The example resources include some technical notes on the dashboard client's OAuth flow. This can be followed to troubleshoot logins and diagnose unexpected group claim values returned to the dashboard. Once you have a working setup, the access token for the developer user will have a payload similar to this:

{
  "sub": "janedoe",
  "purpose": "access_token",
  "iss": "https://localhost:8443/oauth/v2/oauth-anonymous",
  "active": true,
  "groups": [
    {
      "type": "",
      "value": "developers",
      "primary": true
    }
  ],
  "token_type": "bearer",
  "client_id": "devops_dashboard_restconf_client",
  "aud": [
    "urn:se:curity:audiences:admin:api",
    "devops_dashboard_restconf_client"
  ],
  "nbf": 1671185832,
  "scope": "openid urn:se:curity:scopes:admin:api",
  "exp": 1671186132,
  "delegationId": "acbb74b4-7d7c-4723-9f4e-eb1af497b950",
  "iat": 1671185832
}

Deployment Pipelines

All of the above configuration should only be done once, typically in a development stage of the pipeline. You can then use parameterized configuration to promote the same setup to other stages of your pipeline. This involves use of shared configuration XML with placeholders:

<client>
   <id>devops_dashboard_restconf_client</id>
   <client-name>DevOps Dashboard Client</client-name>
   <description>The OAuth client that is used to login to the DevOps dashboard.</description>
   <logo>data:image/svg+xml;base64,CjxzdmcgdmVyc2lvbj0iMS4xIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB4PSIwcHgiIHk9IjBweCIgd2lkdGg9IjE2MHB4IgoJIGhlaWdodD0iMTYwcHgiIHZpZXdCb3g9IjAgMCA0My42IDQzLjYiIHN0eWxlPSJvdmVyZmxvdzp2aXNpYmxlO2VuYWJsZS1iYWNrZ3JvdW5kOm5ldyAwIDAgNDMuNiA0My42OyIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI+CjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+Cgkuc3Qwe2ZpbGw6I0ZGRkZGRjtzdHJva2U6IzYyNkM4NztzdHJva2Utd2lkdGg6MS4xMDQ1O3N0cm9rZS1taXRlcmxpbWl0OjEwO30KCS5zdDF7ZmlsbDojNjM2RDg2O30KCS5zdDJ7ZmlsbDojNjI2Qzg3O30KCS5zdDN7ZmlsbDpub25lO3N0cm9rZTojNjI2Qzg3O3N0cm9rZS13aWR0aDoxLjEwNDU7c3Ryb2tlLW1pdGVybGltaXQ6MTA7fQo8L3N0eWxlPgo8ZGVmcz4KPC9kZWZzPgo8cGF0aCBjbGFzcz0ic3QwIiBkPSJNMzksNDNINC42Yy0yLjIsMC00LTEuOC00LTRWNC42YzAtMi4yLDEuOC00LDQtNEgzOWMyLjIsMCw0LDEuOCw0LDRWMzlDNDMsNDEuMiw0MS4yLDQzLDM5LDQzeiIvPgo8Y2lyY2xlIGNsYXNzPSJzdDEiIGN4PSI2LjQiIGN5PSI0LjQiIHI9IjEuNCIvPgo8Y2lyY2xlIGNsYXNzPSJzdDEiIGN4PSIxMi4yIiBjeT0iNC40IiByPSIxLjQiLz4KPGNpcmNsZSBjbGFzcz0ic3QxIiBjeD0iMTcuOSIgY3k9IjQuNCIgcj0iMS40Ii8+CjxnPgoJPGc+CgkJPHBhdGggY2xhc3M9InN0MiIgZD0iTTMxLjksMjZsLTAuMywwLjNjLTEuNSwxLjUtMy4zLDIuMy01LDIuM2MtMi43LDAtNC43LTItNC43LTQuOGMwLTIuOCwxLjktNC44LDQuNi00LjhjMS42LDAsMy40LDAuNyw0LjcsMS44CgkJCWwwLjMsMC4ybDIuNi0yLjdsLTAuMy0wLjJjLTItMS43LTQuOC0yLjctNy41LTIuN2MtMywwLTUuNSwxLjQtNywzLjVoLTQuN2wtMC4zLDIuM2gzLjljLTAuMSwwLjQtMC4yLDAuOS0wLjMsMS4zSDEybC0wLjMsMi4zCgkJCWg2LjFjMC4xLDAuNSwwLjEsMC45LDAuMywxLjNoMGgtMC4zSDkuM2wtMC4zLDIuM2g4LjdoMC4zaDEuMWMxLjUsMi4yLDQuMSwzLjUsNy4yLDMuNWMzLjksMCw2LjYtMiw3LjktMy4ybDAuMy0wLjNMMzEuOSwyNnoiLz4KCQk8cG9seWdvbiBjbGFzcz0ic3QyIiBwb2ludHM9IjExLjQsMjIuNiA5LjYsMjIuNiA5LjQsMjQuOSAxMS4xLDI0LjkgCQkiLz4KCTwvZz4KPC9nPgo8bGluZSBjbGFzcz0ic3QzIiB4MT0iMC42IiB5MT0iOC4zIiB4Mj0iNDMiIHkyPSI4LjMiLz4KPC9zdmc+Cg==</logo>
   <no-authentication>true</no-authentication>
   <redirect-uris>#{ADMIN_BASE_URL}/admin/dashboard/assisted.html</redirect-uris>
   <proof-key>
      <require-proof-key>true</require-proof-key>
   </proof-key>
   <refresh-token-ttl>disabled</refresh-token-ttl>
   <audience>urn:se:curity:audiences:admin:api</audience>
   <audience>devops_dashboard_restconf_client</audience>
   <scope>openid</scope>
   <scope>urn:se:curity:scopes:admin:api</scope>
   <user-authentication>
      <allowed-authenticators>htmlform</allowed-authenticators>
      <allowed-post-logout-redirect-uris>#{ADMIN_BASE_URL}/admin/dashboard/assisted.html</allowed-post-logout-redirect-uris>
   </user-authentication>
   <allowed-origins>#{ADMIN_BASE_URL}</allowed-origins>
   <capabilities>
      <code />
   </capabilities>
</client>

Conclusion

This tutorial showed how to get up and running with the DevOps dashboard, starting from a default docker deployment of the Curity Identity Server. The dashboard provides a productive and secure way for employees to manage customer user accounts. It also enables you to distribute security management across teams in your organization.