The DevOps Dashboard is a simplified User Interface (UI) that allows users to perform a limited set of administrative operations, namely:
These limited functions are often needed by developers and operators, respectively. Thus, the DevOps Dashboard can be made accessible to these two constituencies without overwhelming them with or granting them access to the entire identity server administrative experience. For this reason, it is recommended in cases where:
Authentication is tied to an OAuth client’s configuration which means that authentication actions, claims providers, any supported user data store, and all of the other functionality in Curity can be used during the authentication and token issuance process. Consequently, the DevOps Dashboard is also possible to protect using multi-factor authentication. In cases where additional identification is necessary to administer OAuth client and alarms, the DevOps Dashboard can be used.
The DevOps Dashboard is not enabled by default. To enable it, do the following:
The easiest way to setup the DevOps Dashboard is using the admin UI. It will make the above trivially simple. To do this in the UI, go to System → Admin Service and follow the wizard that starts when RESTCONF is enabled or enable the DevOps Dashboard if OAuth-protected RESTCONF is already enabled. The XML configuration and CLI commands can be obtained from the config created by the UI.
Once enabled, it can be accessed from the admin UI login page or the specific URL, which is https://localhost:6749/admin/dashboard by default. An example of this is shown in Fig. 39.
Fig. 39 Admin UI login screen with a button to the DevOps Dashboard when it is enabled
If the base URL or listening port of the administrative service is changed from the default, this URL will reflect this. It will continue to be accessible with the correct URL on the Curity admin UI login screen at all times.
Example configuration for enabling the DevOps Dashboard can be seen in listing Listing 133:
There are many requirements of the OAuth client that is used by the DevOps Dashboard. A compatible client is created if the DevOps Dashboard is setup in the admin UI. For the sake of reference, they are listed here:
Where $ADMIN_BASE_URL is either either:
For instance, the default is https://localhost:6749 and an example of what it might be if base URL is explicitly configured might be https://idsvr.example.com.
Also, this client will need to make cross-origin (CORS) request to the revoke endpoint in the selected OAuth profile. For this reason, the allowed-origins in the environment where the service role that hosts the profile’s revoke endpoint is located will need to include $ADMIN_BASE_URL.
Do not use the same OAuth client for any other purpose than the DevOps Dashboard.
Example configure of an OAuth client that can be used with the DevOps Dashboard is shown in Listing 134:
<client-name>DevOps Dashboard Client</client-name>
<description>The OAuth client that is used to login to the DevOps dashboard.</description>
The CORS settings described above can be configured with settings such as these:
As described in the Access Control section of the Configuration Guide, permissions to configuration can be set for various groups. Typically, these permissions are defined for users in the NACM portion of the configuration tree. When working with the DevOps Dashboard, however, it is common to have dozens or even hundreds of different development teams who should have access to different OAuth client and alarms. To simplify the management of groups, it is possible, and recommended at such large scales, to store these groups externally, outside of the NACM portion of the configuration data model. This can be done by including a group claim in the access token that is issued to the RESTCONF client used by the DevOps Dashboard. The mechanism to obtain the groups and include them in this particular claim can be any that are supported. For instance, an authentication-subject-claims-provider claims provider could be used to obtain the claim value from the authenticated attributes; the groups for a each particular user may then be returned during authentication from an LDAP credential manager, for instance. Refer to Scopes and Claims for more details on how to setup claims and scopes.
Be aware that the admin node that runs the dashboard is not built for high available scenarios like the run-time nodes of a cluster. There can be only one admin node in a cluster, and this is the only service that hosts the DevOps Dashboard and the RESTONF API that it consumes. As a result, if this node goes down, the DevOps Dashboard will be inaccessible. Also, if the database used for tokens in the configured OAuth profile goes down, login will be blocked. Alarms for database issues will be generated, and the status endpoint of the admin node is always available for determining liveliness. These should be used to take action in case of issues.