CyberArk (OIDC)

Overview

Configure Maverics to use CyberArk as an identity provider using the OpenID Connect (OIDC) protocol.

Configure Identity Fabric

Use a Secret Provider
Strata recommends implementing a secret management system for use in Production. Maverics connects with multiple secret management systems, which keep sensitive information that Orchestrator instances retrieve during startup. To cite a secret from your provider, enclose the name in angle brackets. (e.g. <app client-id>).

Name	Description	Example
Name	A unique identifier for the connector configuration. This cannot be changed once set.	mavericsOIDC
OIDC Well Known URL	The URL that returns OpenID Connect metadata about the OIDC authorization server.	`https://example.com/.well-known/openid-configuration`
OAuth Client ID	The OAuth client ID registered with the OIDC provider.	exampleID <client_ID_from_secret_provider>
OAuth Client Secret	The OAuth client secret associated with the client ID.	exampleSecret <client_secret_from_secret_provider>
Redirect URL(s)	A list of allowed redirect URIs for the login flow.	`https://host1.example.com/oidc, https://host2.example.com/oidc`
Logout Callback URL(s)	A list of allowed redirect URIs for the logout flow.	`https://host1.example.com/logout, https://host2.example.com/logout`
Scopes	A space-delimited string specifying the scopes to request during authentication.	`openid profile email custom-scope`
Proof Key for Code Exchange (PKCE)	Enable or disable Proof Key for Code Exchange (PKCE). When set to `enabled`, PKCE enhances security by requiring a code verifier during authentication. When `disabled`, PKCE is disabled, which may reduce security for public clients.

JSON deployed to the orchestrator

{
  "connectors": [
    {
      "name": "mavericsOIDC",
      "type": "oidc",
      "oidcWellKnownURL": "https://example.com/.well-known/openid-configuration",
      "oauthClientID": "exampleID",
      "oauthClientSecret": "exampleSecret",
      "oauthLoginRedirect": {
        "urls": [
          "https://host1.example.com/oidc",
          "https://host2.example.com/oidc"
        ]
      },
      "oauthLogoutRedirect": {
        "urls": [
          "https://host1.example.com/logout",
          "https://host2.example.com/logout"
        ]
      },
      "disablePKCE": false,
      "scopes": "openid profile email custom-scope"
    }
  ]
}

Configuring Maverics in CyberArk

Follow CyberArk documentation to set up a custom OpenID Connect application.
In the app's Trust settings tab, in the Service Provider configuration, check Login initiated by the relying party (RP)
Add the following Authorized redirect URI: example https://localhost:8443/oidc
In Maverics, go to Identity Fabric and click CyberArk-OIDC from the list.
From the CyberArk app settings, copy the OpenID Connect metadata URL and paste it into the OIDC Well Known URL field in Maverics.
From the CyberArk app settings, copy the OpenID Connect client ID and secret. Go back to Maverics and paste them into the corresponding fields. Click Update

Identity Service Health Monitoring

Identity Service Health Monitoring is a feature used as part of Identity Continuity and is available for OIDC, SAML, and LDAP identity services. When enabled, this feature allows the orchestrator to continuously poll the identity service and trigger an alert if it can't be reached. In addition, you can create a manual failover mechanism for break-glass scenarios with the custom health check endpoint capability.

You will need to configure Identity Service Health Monitoring for each identity service used in your continuity strategy.

When this feature is enabled, the following fields can be configured:

Name	Description	Example
Polling Frequency	The interval between each health check of the identity service. Can be set in seconds, minutes, or hours.	`30s`
Timeout	The maximum wait time for a response. Can be set in seconds, minutes, or hours.	`5s`
Failover Threshold	The number of consecutive negative (down) health check results to trigger a failover.	4
Fallback Threshold	The number of consecutive positive (up) health check results to trigger a fallback.	4
Custom Health Check	Enabling this allows you to override the behavior of monitoring IDP availability. This can be used use custom signals for IDP health or for a break-glass scenario to manually trigger failover and fallback behaviors.
Custom Health Check Endpoint	The endpoint to use for the custom health check. The value must be a fully qualified URL.	`https://example.com/health`
Expected Status Codes	(Optional) The HTTP status codes that the custom health check returns to be considered healthy.	`200, 201`
Response Body Matcher	(Optional) A matcher that verifies the expected value in the response body of a health check.	`'"status": "up"'`