DevOps Dashboard¶

The DevOps Dashboard is a simplified User Interface (UI) that allows users to perform a limited set of administrative operations, namely:

OAuth client management
Viewing alarms

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:

Developers need to manage OAuth clients independent of identity server administrators
Operators need to view more details about an alarm but should not have full access to Curity

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.

Enabling the DevOps Dashboard¶

The DevOps Dashboard is not enabled by default. To enable it, do the following:

Enable OAuth-based access to the RESTCONF API
Enable the DevOps Dashboard
Specify some OAuth client to be used to authenticate to the DevOps Dashboard and add that client to the list of allowed clients that can call the RESTCONF API
Add the admin UI’s base URL (or the default if not configured) to the environment’s allowed origins.

Tip

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. 40.

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 102:

Listing 102 The admin service settings to enable the DevOps Dashboard¶

<admin-service>
  <http>
    <ssl-server-keystore>server-key-1</ssl-server-keystore>
    <restconf>
      <oauth xmlns="https://curity.se/ns/conf/profile/oauth">
        <oauth-profile>my-good-oauth-profile</oauth-profile>
        <client>devops_dashboard_restconf_client</client>
      </oauth>
    </restconf>
    <devops-dashboard xmlns="https://curity.se/ns/conf/profile/oauth">
      <client>devops_dashboard_restconf_client</client>
    </devops-dashboard>
  </http>
</admin-service>

Requirements of an OAuth Client¶

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:

The client must be a public client (i.e., one that has no-authentication configured).
The redirect URI list must contain $ADMIN_BASE_URL/admin/dashboard/assisted.html.
Use of a proof key should be required.
The scopes urn:se:curity:scopes:admin:api and openid must be added.
The audience must include the client’s ID and urn:se:curity:audiences:admin:api.
The allowed-post-logout-redirect-uris under the user-authentication setting should include $ADMIN_BASE_URL/admin/dashboard/assisted.html.
The only capability required is code; allowing any others is not recommended.
refresh-token-ttl should be set to disabled; otherwise, refresh tokens will be issued to the client, which it doesn’t use.
The allowed origins must include $ADMIN_BASE_URL.
The client may have a name, description, and logo. validate-port-on-loopback-interfaces can be set to true or false.

Where $ADMIN_BASE_URL is either either:

The admin base URL if configured; or
https:// if an SSL key store is configured or http:// otherwise; followed by localhost; and a colon and then the listening port.

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.

Warning

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 103:

Listing 103 The minimal configuration necessary to create an OAuth client that can be used with the DevOps Dashboard¶

<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>
    <no-authentication>true</no-authentication>
    <redirect-uris>https://localhost:6749/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>my-good-authenticator</allowed-authenticators>
      <allowed-post-logout-redirect-uris>https://localhost:6749/admin/dashboard/assisted.html</allowed-post-logout-redirect-uris>
    </user-authentication>
    <allowed-origins>https://localhost:6749</allowed-origins>
    <capabilities>
      <code/>
    </capabilities>
</client>

The CORS settings described above can be configured with settings such as these:

Listing 104 Configuration that will enable CORS requests from the DevOps Dashboard¶

<config xmlns="http://tail-f.com/ns/config/1.0">
  <environments xmlns="https://curity.se/ns/conf/base">
    <environment>
      <services>
        <zones>
          <default-zone>
            <allowed-origins-for-cors>https://localhost:6749</allowed-origins-for-cors>
          </default-zone>
        </zones>
      </services>
    </environment>
  </environments>
</config>

Group Access¶

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.

Availability¶

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.