Set up Identity Continuity™

With Identity Continuity™, Maverics can gracefully manage unplanned IDP outages without downtime, keeping mission-critical workloads available securely and continuously. Maverics gives you the ability to turn on Identity Continuity™ for any of your identity services and IDPs.

Identity continuity in IAM refers to ensuring that an individual’s digital identity remains consistent and intact across various systems, applications, and time periods. This involves maintaining the same user identity, access permissions, and roles despite changes in job roles, system updates, or other organizational changes.

When applied to IAM, the differences between backup and continuity are essentially as follows:

Identity Backup: In IAM, this refers to preserving essential identity information (user credentials, access rights, role assignments) so it can be restored if needed. This helps in recovering from data loss or corruption.

Identity Continuity™: In IAM, this involves ensuring that users have consistent and uninterrupted access to necessary resources and applications. This means that any unexpected interruption or downtime of identity services do not disrupt user access to their applications.

While backups in IAM are about creating restorable copies of identity information, continuity is about ensuring uninterrupted and seamless access to systems and resources over time.

Maverics supports two primary use cases for identity continuity:

• Cloud IDP to on-premises
  • You use a cloud-based IDP and it fails over to your own LDAP or Active Directory deployment
• Cloud IDP to cloud IDP
  • You use a cloud-based IDP and it fails over to another cloud IDP

In this guide, we’ll walk you through deploying an orchestrator, creating a continuity strategy using your two test IDPs, and deploying the configuration to a local environment for the orchestrator instance to consume and run. We’ll cover the following steps:

• Access to Identity Continuity™
• Continuity Recipe
• Deploying an orchestrator
• Identity services supported by continuity
  • Identity Service Health Monitoring
• Create a continuity strategy
  • Schema Abstraction Layer™
• Configure an application
• Configure your user flow
• Test your continuity strategy
  • Test primary
  • Test failover to secondary
  • Test tertiary
  • Test fallback
  • Test fallback 2

Access to Identity Continuity™

To confirm your access to Identity Continuity™ sign into Maverics and click Identity Fabric in the sidebar. On the Identity Fabric page, you should see Continuity Strategy at the top of the list of Identity Services.

If you do not have access to the Continuity Strategy, you can request access by emailing [email protected] with your account ID. To find your account ID, click your user ID in the upper right corner of the screen and go to Accounts. Click your account name on the Accounts page. The Account ID appears in the URL of the next page, as follows:

https://maverics.strata-staging.io/accounts/{{your-account-id}}

Continuity Recipe

The file below contains configuration for three IDPs (Entra ID, Okta, and LDAP), two applications (Canary Bank and Salesforce), and two user flows.

• Download: 03_Continuity_Guide.tar.gz

After logging into Maverics, you’ll land on the dashboard.

The dashboard provides a summary of your existing identity fabrics, applications, and user flows.

1. Click Import Identity Orchestration Recipe.
2. On the next page, click Choose File and select the 03_Continuity_Guide.tar.gz file you’ve downloaded.
3. Click Create.

4. On the next page, ensure None is selected for Type, and click Save Import. You will return to the Dashboard and see the following items in each section:
   • Identity Fabric: Entra-ID, Okta, ldap
   • Applications: Canary-Bank, salesforce-eval
   • User Flows: Continuity - Legacy Apps, Continuity - Modern SAML App (Salesforce)

Deploying an orchestrator

Before downloading and deploying an orchestrator, you must create an environment. Environments define cloud storage containers where you can deploy user flow configuration and the Orchestrators that will read that configuration for your applications.

Use our Learning Center tutorial, Getting Started: Evaluation Environment, to quickly and easily create an evaluation environment.

For detailed information on how to set up an environment with different cloud storage services, see Configure environments. After you’ve created your environment, you can download and install the orchestrator. See Evaluation Installation for instructions on how to start your orchestrator.

Identity services supported by continuity

To set up Identity Continuity™, you must have more than one identity service defined in your identity fabric. The following table lists which identity services are supported in continuity.

The recipe includes access to preconfigured Entra ID, Okta, and LDAP services, as well as test user credentials to test your user flows in a browser. To explore these IDP configurations, go to Identity Fabric and select each IDP from the list.

You will need to edit all identity services to enable Identity Service Health Monitoring.

Identity Service Health Monitoring

When setting up your identity services, ensure that Identity Service Health Monitoring for each service is enabled. When enabled, this feature allows the orchestrator to continuously poll the identity service and trigger an alert if it can’t be reached.

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

When Identity Health Service Monitoring is enabled, the following fields can be configured:

• Polling frequency: The interval between each health check of the identity service. This can be set in seconds, minutes, or hours.
• Timeout: The maximum wait time for a response. This can be set in seconds, minutes, or hours.
• Failover threshold: The number of consecutive negative (down) health check results to trigger a failover.
• Fallback threshold: The number of consecutive positive (up) health check results to trigger a fallback.

When Custom Health Check is also enabled, the following fields can be configured:

• Custom health check endpoint: A custom endpoint to control failover and fallback actions (e.g., https://example.com/health).
• Expected status codes: The http status codes that the custom heath check returns to be considered healthy. Accepts comma seperated values (e.g., 200, 300, 400).
• Response body matcher: A matcher that verifies the expected value in the response body of a health check (e.g., ‘Up’ or ‘Down’).
• Header Keys and Values: Headers specifically used for the custom health check endpoint
• Skip TLS Verification: When enabled, the orchestrator does not validate the certificate chain or hostname. This option is unsuitable for production. Use with extreme caution.
• CA Path: (Optional) The path to your certificate authority when using self signed certs.

For OIDC-based identity services, the health check will call the well-known endpoints and the authorization servers you’ve defined. If the health check fails to reach these endpoints, the orchestrator debug logs will report the string below and it will trigger a failover.

LDAP/AD identity services will check the server URL and attempt to make a bind. If these actions fail, the orchestrator logs will report the string below and it will trigger a failover.

For testing purposes, we recommend setting the polling frequency and timeout to 10 seconds.

New identity health service event

This is a new identity health service monitoring log event. If the health check fails, you will see the following message in the logs.

level=debug msg="idp health check failed: well-known metadata unavailable" error="failed to load OIDC well-known metadata: failed to get OpenID well-known metadata: Get \"https://dev-467635.Okta.com/oauth2/default/.well-known/openid-configuration\": Forbidden" name=Okta status=false

Create a continuity strategy

Now that you’ve set up at least two identity services, you can create a continuity strategy.

1. Go to Identity Fabric and select Continuity Strategy.
2. Enter a name for your continuity strategy and click the check mark.
3. Select the primary and secondary identity services you want to use for your failback strategy. The menu lists identity services you’ve already configured in the previous section. Select your primary identity service first, and then select your secondary identity service. If applicable, select your third identity service last.

Next, configure the Schema Abstraction Layer™, matching the attributes listed below:

• email > preferred_username > email > mail

Schema Abstraction Layer™

The Schema Abstraction Layer™ creates a map linking the attributes required by applications in user flows to the claims available in each identity service. In case of a failover, the new session will use this map to retrieve the necessary claims.

To effectively use the schema abstraction layer, you’ll start by developing a user flow for your application, pinpointing the essential claims, headers, or authorization rules it requires. Within this flow, you’ll specify the names of the claims needed by your application.

You’ll then select a continuity strategy from your list of providers to ensure a seamless user experience, even in the event of a failover.

Finally, you’ll map these claim names to the ones defined in the schema abstraction layer, ensuring consistent and efficient management of user attributes across different identity services. This approach streamlines the integration process and maintains reliability in user sessions.

Configure an application

The recipe you’ve imported includes a pre-configured application. You will not need to edit this app.

For future reference in configuring a new app, Maverics supports several types of applications including header-based, OIDC-based, SAML-based, and custom JSON code.

For more information on how to create an app, see Configure applications.

Configure your user flow

The recipe you’ve imported includes a pre-configured user flow called, Continuity - Legacy Apps.

1. Click this user flow either from the User Flows page or from your Dashboard.
2. On the user flow information page, scroll down to Access Control Policies and click the heading Resource location: /
3. Select the continuity strategy you created from the Select an authentication provider dropdown menu.
4. Under Headers, click the pencil icon to edit the SM_USER header. Change the provider to your failover strategy, and select email as the attribute.
5. Click Commit and Deploy.

For information on how to set up other user flows, see the following docs:

• Proxy app user flow
• SAML app user flow
• OIDC app user flow

Where to reference the continuity strategy depends on the type of app you’ve created. For SAML and OIDC app user flows, you can select the continuity strategy from the Authentication menu.

For proxy app user flows, you will need to create an access control policy for a resource location, and select the continuity strategy as an authentication provider for each resource location configured.

Test your continuity strategy

After committing your continuity strategy, a modal appears where you can add a comment and enable simulation to test the failover behavior and the Schema Abstraction Layer™.

To enable the simulation, toggle the switch and enter the time interval in seconds for each status change. A 60-second interval will trigger as depicted in the bar chart below:

This will result in the following scenario after deploying the user flow:

Test primary

1. You will be initially able to login to Canary Bank using the provided Entra ID credentials (your primary IDP) for the first 60 seconds.
   1. In a new incognito or private window go to https://localhost:8443
   2. Log into the Entra ID page using:
      • username: [email protected]
      • password: pms2024@!
   3. Close the incognito window.

Test failover to secondary

2. After 60 seconds, Entra ID will appear unavailable and the Canary Bank login will failover to Okta (your secondary IDP). You should then be able to log into Canary Bank using the provided Okta credentials for the next 60 seconds.
   1. In a new incognito or private window go to https://localhost:8443
   2. Log into the Okta page using:
      • username: [email protected]
      • password: pms2024@!
   3. Close the incognito window.

Test tertiary

3. After a full minute from deploying the user flow, Okta will appear unavailable, and the Canary Bank login will failover to LDAP (your tertiary IDP). You should then be able to log into Canary Bank using the provided LDAP credentials.
   1. In a new incognito or private window go to https://localhost:8443
   2. Log into the LDAP page using:
      • username: [email protected]
      • password: password
   3. Close the incognito window.

Test fallback

4. After three minutes, Okta will come back online and the Canary Bank Login will fall back to Okta again.
   1. In a new incognito or private window go to https://localhost:8443
   2. Log into the Okta page using:
      • username: [email protected]
      • password: pms2024@!
   3. Close the incognito window.

Test fallback 2

5. After a full four minutes deploying the user flow, Entra ID will come back online, and the Canary Bank login will fall back to Entra ID again.
   1. In a new incognito or private window go to https://localhost:8443
   2. Log into the Entra ID page using:
      • username: [email protected]
      • password: pms2024@!
   3. Close the incognito window.

By following the steps outlined in this guide, you have successfully set up a Maverics continuity strategy for use with any application, laying the groundwork for a robust and secure identity management system. As you proceed, remember that each component plays a crucial role in enhancing the security and efficiency of your application integration, ensuring that your organization’s identity management framework is both resilient and adaptable. With Maverics, you’re now equipped to navigate the complexities of digital identity management, fostering a secure and user-friendly environment for your users.