Use Anything-as-a-Source

Anything-as-a-Source (XaaS) allows you to integrate any source of truth with Okta, and realize the benefits of HR-driven provisioning from any source of truth. XaaS gives you the flexibility to define the terms of synchronization between Okta and the source of truth. Alternatively, some identities don't require representation in Okta, and XaaS can filter out irrelevant data, syncing only the appropriate identities.

Prerequisites

  • Access to Okta profile sourcing capabilities.
  • A source of truth from which you can extract data with the public API, report, file export, or some other mechanism.
  • An API client to make API calls associated with the XaaS feature. This could be an automation platform (such as Okta Workflows) or your own custom-hosted code.

  • The API client must be authorized to call Okta APIs. This is achieved by setting up an OAuth 2.0 service app (or using the integrated OAuth 2.0 client in Okta Workflows).

  • Access to the Okta Workflows platform if you're using Okta Workflows.
  • Your org needs to have the Identity Source Apps feature enabled. Contact your Okta account team to enable this feature.

Build an XaaS integration

Building an XaaS integration involves the following steps:

  1. Create and configure a Custom Identity Source.
  2. Synchronize data using a Custom Identity Source.

Create and configure a Custom Identity Source

Before synchronizing data from your source of truth, you must first create an integration in your Okta org by following these steps:

  1. In the Admin Console, go to ApplicationsApplications.

  2. Click Browse App Catalog.
  3. Search for and select Custom Identity Source, and then click Add Integration.
  4. Optional. Specify a name for your new integration and indicate if you want to display the app to users.
  5. Click Done.
  6. Go to the Provisioning tab.
  7. Select Integration under Settings.
  8. Click Configure API Integration, and then select Enable API integration.
  9. Select To Okta under Settings.

    "To App" provisioning isn't supported for this integration type and these settings are ignored.

  10. Configure the integration. For example:
  • Configure whether new users should be confirmed manually or automatically by Okta
  • Configure how Okta determines if a new user is a match to an existing user and whether this should be confirmed manually or automatically
  • Specify if this integration serves as a profile source in Okta

You can find the identity source ID (referred to as ${identitySourceId}) in the URL for the instance. This ID is needed to configure the source, which is highlighted in the following URL:

Map attributes for a Custom Identity Source

Add attributes to the schema for your integration to specify the data that's sent to Okta from the custom identity source.

  1. In the Admin Console, go to DirectoryProfile Editor.

  2. Optional. In the Filters section on the left, select Apps.
  3. Find and select your custom identity source among the integrations listed.
  4. For each attribute that should be mapped to Okta (for example, for inclusion in the Okta profile or use in a profile mapping), do the following:
    1. Click Add Attribute.
    2. Select string as the data type of the attribute.

      Identity source schemas for XaaS only support string attributes.

    3. Enter a display name, variable name, and (optionally) a description for the new attribute. Okta Expression Language is accepted.
    4. Specify any other relevant constraints, such as whether the attribute is required, the range, or length constraints.
    5. If you have more attributes to add, click Save and Add Another. When you've added the final attribute, click Save.
    6. Go to the Mappings tab on the Profile Editor page. Click Configure User Mappings.
  5. Create mappings from the custom identity source (appuser) attributes on the left to the Okta user on the right.

If a desired attribute hasn't been added to the Okta user profile yet, see Add custom attributes to apps, directories, and identity providers

Synchronize data with a Custom Identity Source

Now that you've added an identity source integration to your Okta organization, you're ready to synchronize data from your source of truth to Okta. This section describes how to use XaaS APIs to perform this synchronization after data has already been extracted from the source.

Deleting a user that's already been matched using API calls deactivates the user in Universal Directory. If the user hasn't already been matched, the user won't appear in Universal Directory.

OAuth 2.0 Client Creation

To ensure secure and standard authorization, you must create a dedicated OAuth 2.0 client app. This is used to obtain the required access token for making API calls. For detailed steps on creating this client, see Implement OAuth for Okta with a service app.

If you're using Okta Workflows as your API client, you will also use an OAuth 2.0 configuration, but the setup is managed directly within the Workflows environment. See Authorization for specific authorization instructions.

Build a custom client for XaaS

For detailed information on how to build a custom client for XaaS, see Build an Anything-as-a-Source custom client integration.

Okta Workflows

Any XaaS API can be called in Okta Workflows using the Okta connector and the Custom API Action card (see Custom API Action (CAPIA) cards). The Okta Workflows API Connector (and other connectors) can be used to call any other public HTTP endpoint. For example, this connector could be used to retrieve data directly from a source of truth like an HR system.

Considerations

  • XaaS can't use import scheduling, import safeguards (app-level or org-level), or user import inline hooks.

  • Bulk imports are limited to 10K users, groups, or memberships per single session.

  • Bulk imports are done at 200 users, groups, or memberships per batch, and up to 50 POST requests can be made in a single import session. The size of each request must not exceed 200 KB.

  • There are no APIs for account matching, linking, or profile mapping.

  • Listing the same user twice in a session can result in data inaccuracy issues (such as a race condition or profile conflict).

  • Sending an empty profile creates an empty user, which isn't recommended by Okta.

  • Connecting XaaS to an existing integration with Okta (such as Workday) can result in data inaccuracy issues, and isn't supported by Okta.