Import from Okta

Directory → People → Import from Okta reads an Okta org through the Okta Management API, shows what would happen to every item, and only writes after you start the import.

What you needCopy Anchor Link

• An IdRa administrator role that can create people and write groups and apps: Super Administrator or Organization Administrator.
• Your Okta org URL, like https://acme.okta.com. IdRa accepts okta.com, oktapreview.com, okta-emea.com, okta-gov.com and okta.mil hosts only, so custom domains are refused: use the org's Okta address.
• An Okta API token (SSWS), created in Okta under Security → API → Tokens while signed in as a Read-only Administrator. A token acts with its creator's permissions, and IdRa only makes GET calls, to:
  • /api/v1/users
  • /api/v1/groups and /api/v1/groups/{id}/users
  • /api/v1/apps

The token stays in your browser tab for the preview and the import, and in server memory during each of those two requests. IdRa never stores it, logs it or returns it. Revoke it in Okta when you finish.

StepsCopy Anchor Link

1. Open Directory → People and select Import from Okta.
2. Enter the org URL and token, then select Preview import. This is the dry run: it writes nothing.
3. Read the report. Every user, group and app is marked Create, Skip or Unsupported, with a reason or what you must redo.
4. Select Start import. If Okta or IdRa changed since the preview, IdRa asks you to preview again, so what runs is what you reviewed.
5. Follow the progress. Download the list of what wasn't imported if you need it.
6. Run the import again whenever you like. Items already in IdRa are skipped, so items that failed get another try and nothing is duplicated.
7. Activate people when you're ready, from each person's page. See the limits below on bulk activation.

What is migratedCopy Anchor Link

An existing person is never changed, apart from joining the Okta groups they're missing.

What you must redoCopy Anchor Link

• Passwords and MFA. Okta doesn't export password hashes or factors. Imported people have no password and receive no email until you activate them, then they set a password and enroll again.
• OIDC apps. Each gets a new client ID. Okta doesn't export client secrets, so rotate the secret on the app's page in IdRa, then update the client ID and secret in the app.
• SAML apps. Install IdRa's metadata in the service provider.
• App assignments. All imported apps start with nobody assigned: assign people or groups on each app.

Not migratedCopy Anchor Link

The report lists these as Unsupported, with the reason:

• Suspended and deactivated users, and users without a valid email or a first and last name.
• Okta's built-in Everyone group (IdRa has its own), and groups sourced from an app or a directory.
• Groups whose name matches an IdRa group managed elsewhere (SCIM, partners).
• Okta's own apps, inactive apps, and sign-on modes with no IdRa equivalent: password vaulting (BROWSER_PLUGIN, SECURE_PASSWORD_STORE), AUTO_LOGIN, BASIC_AUTH, WS_FEDERATION and SAML_1_1.
• SAML catalog integrations, because Okta doesn't expose their settings. Also SAML apps using single logout, signed requests, group filters or attribute expressions other than user.<attribute>.
• OIDC apps with wildcard redirect URIs.

These aren't read at all, and don't appear in the report:

• Admin roles. No imported person gets an IdRa admin role. Grant roles in Security → Administrators.
• App assignments, policies, MFA factors, group rules, network zones, identity providers, API tokens, and profile attributes not defined in your Profile Editor.

There is no bulk activation yet: activate people one at a time from their page.

LimitsCopy Anchor Link

The read runs inside the preview and import requests, because the token isn't stored. A very large org could outlast a proxy's request limit; the read writes nothing, so running it again is safe. IdRa waits and retries when Okta answers 429, following X-Rate-Limit-Reset, up to three times per call.