Okta (SAML)

  • 2 minute(s) read
Prev Next

Configure Maverics to use Okta as an identity provider using the SAML protocol.

Identity Fabric/Okta (SAML)→Configure Settings→Use for authentication in any type of user flow

Configure Identity Fabric

Use a Secret Provider

Production settings ought to implement a secret management system. Maverics connects with multiple secret management systems, which keep secrets that Orchestrator instances retrieve during startup. To cite a secret from your provider, enclose the name in angle brackets. (e.g. <app client-id>)

Learn more about Secret Providers

Field Name

Description

Example

Name

A friendly name for your SAML service.

samlClient

Metadata URL

This is the metadata URL from the application configured in the SAML service. This setting will accept a file:/// URI if the metadata file is saved on a filesystem accessible to the Orchestrator user.

https://saml-idp.com/FederationMetadata/2007-06/FederationMetadata.xml

Consumer Service (ACS) URL

The URL that the SAML service will use to POST the SAML response. The Maverics SAML ACS handler will be served on this URL, and it should not conflict with the path of any application resources. The path can be arbitrary (e.g. /maverics-saml or /saml-handler), but must match the service's configuration for the specified Entity ID.

https://orchestrator.example.com/acs

Logout Callback URL

The URL that the SAML server will call back once logout is successful. Ensure your SAML service's logout URL setting matches the URL value specified here.

https://orchestrator.example.com/logout

Identifier (Entity ID)

The unique application entity ID assigned to the application.

MavericsOrchestrator

Service Provider Certificate

(Optional) The path to the certificate that will be used to sign SAML authentication requests.

./my-sp-cert.pem, <sp-cert.pem>

Signing Private Key Path

(Optional) The path to the private key that will be used to sign SAML authentication requests.

./my-private-key.pem,  <private-key.pem>

Name ID Format

Defines the SAML Subject NameID format specified for the app in your SAML service.

urn:oasis:names:tc:SAML:2.0:nameid-format:entity

IdP Initiated Login

Accept unsolicited SAML responses from the configured IDP. This is disabled by default.


Allowed Redirect URLs

Specifies the allowed redirect URLs for IdP-initiated login.

https://alpha-app.example.com/dashboard, https://beta-app.example.com/index.html

JSON deployed to the orchestrator

{
  "connectors": [
    {
      "name": "samlClient",
      "type": "saml",
      "samlEntityID": "MavericsOrchestrator",
      "samlMetadataURL": "https://saml-idp.com/FederationMetadata/2007-06/FederationMetadata.xml",
      "samlConsumerServiceURL": "https://orchestrator.example.com/acs",
      "samlLogoutCallbackURL": "https://orchestrator.example.com/logout",
      "samlNameIdFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:entity",
      "samlIDPInitiatedLogin": {
        "enabled": true,
        "allowedRedirectURLs": [
          "https://alpha-app.example.com/dashboard",
          "https://beta-app.example.com/index.html"
        ]
      }
    }
  ]
}

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:

NameDescriptionExample
Polling FrequencyThe interval between each health check of the identity service. Can be set in seconds, minutes, or hours.30s
TimeoutThe maximum wait time for a response. Can be set in seconds, minutes, or hours.5s
Failover ThresholdThe number of consecutive negative (down) health check results to trigger a failover.4
Fallback ThresholdThe number of consecutive positive (up) health check results to trigger a fallback.4
Custom Health CheckEnabling 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"'

Related articles