Okta Connector

The Okta connector provides identity mappings for each user based on the apps that they use.

Note: As part of Atolio Configuration, this connector should be selected as Identity Provider if it is used to resolve app-user mappings.

Service Account and Required Permissions

Okta API tokens inherit the permissions of the user that creates them, so we recommend creating a dedicated service account rather than using a personal admin account. The connector only performs read operations against Okta (users, groups, applications, application users, and the System Log).

Assign one of the following to the service account:

• Read-only Administrator (built-in role) — the simplest option, and the lowest-privilege built-in role that covers everything the connector needs.
• A custom admin role with these read permissions, scoped to all users, all groups, and all apps:
  • okta.users.read
  • okta.groups.read
  • okta.apps.read
  • okta.logs.read
  • okta.reports.read

Note: The connector tolerates per-request 403 Forbidden responses and continues processing other events, so an under-scoped token will produce incomplete data rather than a hard failure. If you scope the role to a subset of users, groups, or apps, anything outside that scope will silently be missing from search results.

Creating an API Token

Sign in as the service account and create the token at https://example.okta.com/admin/access/api/tokens (replacing example.okta.com with your Okta domain). See Okta’s Create an API token guide for full details.

Note: Okta revokes API tokens after 30 days of inactivity. The connector polls Okta continuously and keeps the token active during normal operation, but if the connector is paused or disabled for an extended period the token will need to be regenerated.

Provide Configuration

Provide the following configuration values to your Deployment Engineer in order to complete these steps:

• Hostname, the host name for your Okta instance (e.g. example.okta.com)
• Token, the API Token created above