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 customers 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 Anything-as-a-Source feature. This could be an automation platform (such as Okta Workflows) or your own custom-hosted code.

  • An active API token that can call Okta APIs.

  • Access to the Okta Workflows platform if you're using Okta Workflows.

Build an Anything-as-a-Source Integration

Building an Anything-as-a-Source 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 the catalog for Custom Identity Source. Select it, 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:

Declare an identity source schema

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. Find your custom identity source among the integrations listed and click Profile.

  3. For each attribute that should be synchronized 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 the data type of the attribute (for example, enum or string).

    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.

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

API Token Creation

First, create an API token by following the steps outlined on Okta Developer. You can also copy this token for use in your API client. If Okta Workflows is being used as the API client, this step isn't required, as the Okta connector has access to an authorized API token.

Build a XaaS custom client

For detailed information on how to build a XaaS custom client, see the guide on Okta Developer.

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.