Configure provisioning for an app integration
Configure an app integration to manage the user lifecycle between Okta and the external app. This task is required whenever you add provisioning to a new or existing app integration.
- Install an app integration that has provisioning capabilities. See Typical workflow for deploying new provisioning app integrations or Typical workflow for adding provisioning to an existing app integration.
- In the Admin Console, go to .
- Enter the name of the app integration in the Search field.
- Click the name of the app integration that you want to configure and click the Provisioning tab.
A Configuration Guide is accessible on the Provisioning settings tab. The guide details the exact settings necessary to set up provisioning between the external app and Okta.
- Click Configure API Integration.
- Select Enable API integration.
- Complete the authentication fields. These may include:
Username: Enter the username for the app admin.
Password: Enter the password for the user account provided.
Token: Enter the security token used to access the external app.
Push Null Values: Select this option to pass null values to Okta.
Import Groups: Selected by default. To remove app groups from Okta, clear the checkbox and then click Continue in the Disable Import Groups dialog box.
- Click Test API Credentials to test your API credentials. If you receive an error, verify and retry your credentials.
-
Click Save.
- From the Settings column on the page, select from the three provisioning configurations: To App, To Okta, and API Integration. For detailed information on available settings, see Configuration settings for To App provisioning, Configuration settings for To Okta provisioning, and Configuration settings for API Integration provisioning.
- Click Edit.
- Select the provisioning options and click Save.
- Optional. Scroll down to the Attribute Mappings section and click Go to Profile Editor.
App integrations that use entitlement management use discovery to automatically map attributes between Okta and the downstream app. Admins can't map attributes for these integrations. See Create SCIM app integrations with entitlement management.
- Click Mappings and click the Okta User to app name tab.
- Edit the attributes and click Save Mappings.
- Click Apply updates now.
Configuration settings for To App provisioning
This page contains settings for all information that flows from Okta into the external app. Not every feature in the following list is available for every app integration.
Click Edit to change configuration settings in the following sections:
- Create Users: Assigns a new external application account to each user managed by Okta. Okta doesn't create an account if it detects that the username specified in Okta exists in the external app. The user's Okta username is assigned by default.
In addition to the user profile, Okta sends a random password in its request to create a user.
- Update User Attributes: Updates the profiles of users assigned to that app integration and syncs those changes to downstream apps. Profile changes made in the external app are overwritten with their respective Okta profile values.
- Deactivate Users: Automatically deactivates user accounts when they're unassigned in Okta or their Okta accounts are deactivated. Okta also reactivates the external application account if the app integration is reassigned to a user in Okta.
- Exclude Username Updates: Prevents the downstream app profile from overwriting the Okta user profile when using the profile push feature.
- Sync Password: Ensures users' external app passwords are always the same as their Okta passwords or allows Okta to generate a unique password for the user. See Synchronize passwords from Okta to Active Directory.
- Profile Attribute Mappings: Use this portion of the page to edit attributes and mappings for Okta app integration and user profiles. See Manage profiles.
Configuration settings for To Okta provisioning
This page contains settings for all information that flows from the external app to Okta.
Click Edit to change configuration settings in the following sections.
- General: Use this section to schedule imports and dictate a username format for Okta to use for imported users. You can also define a percentage of acceptable app integration assignments before the import safeguard feature is automatically triggered. If the Okta username is overridden due to mapping from a provisioning-enabled app integration, the custom mapping appears in this section. See Import safeguards.
- User Creation & Matching: Matching rules are used when importing users from all external apps and directories that allow importing. Establishing matching criteria allows you to specify how an imported user should be defined as a new user or mapped to an existing Okta user.
- Imported user is an exact match to Okta user if: The matching criteria that establishes whether an imported user exactly matches an existing Okta user. Choose any combination from the list of options to establish your criteria. For the new imported user to be considered an exact match, each option that you select must be true. If you choose the third option, the first and second choices are disabled.
- Allow partial matches: Partial matches occur when the first and last names of an imported user match those of an existing Okta user, but the username or email address do not.
- Confirm matched users: Select to automate the confirmation or activation of existing users. If the option isn't selected, matches are confirmed manually.
- Confirm new users: Select to automate the confirmation or activation of a newly imported user. If this option is selected, you can clear it during import confirmation. This feature doesn't apply for users who exist in Okta.
- Profile & Lifecycle Sourcing: Use this section to allow the current external app to act as a profile source for Okta users. If enabled, the external app appears in the list of profile sources on the profile sources page. See Profile sourcing.
- Allow app to source Okta users: Enable sourcing and determine what action occurs when a user is deactivated or reactivated in an app integration. Only the highest priority profile source for that Okta user can deactivate or suspend an Okta user. To verify the highest priority profile source, review the profile sources page. See Profile sourcing.
- When a user is deactivated in the app: Choose Do Nothing to prevent activity in the external app from controlling the user life cycle. This option still allows for profile source control of attributes and mappings. The other choices are deactivating or suspending the user.
- When a user is reactivated in the app: Decide if suspended or deactivated Okta users should be reactivated when they have been reactivated in the external app.
When a user is reactivated in the external app, the user profile must be an exact match to the Okta profile for the reactivation to also occur in Okta. If the profile isn't an exact match, then after importing the reactivated users, they appear in the Pending Activation state.
- Import Safeguards: The import safeguard settings define the maximum percentage of users in an org that can be unassigned while still allowing the import to proceed. App-level and organization-level safeguards are enabled by default and set at 20 percent. See Import safeguards.
- Inline Hooks: Use this section to add custom logic to the process of importing new users into Okta from an external app. You can resolve conflicts in profile attributes and control whether imported users are treated as matches for existing users. To enable an import inline hook, see Inline hooks.
- OktaAttribute Mappings: Use this portion of the page to edit attributes and mappings for Okta app integration and user profiles. See Manage profiles.
Configuration settings for API Integration provisioning
Some external apps require a token to authenticate against their API. Click Authenticate with App Name to generate a token. You're redirected to the external app where you must authenticate to obtain your token.
The API endpoints of some external appa can trigger an import of that app's groups into Okta when the API is configured. This is expected behavior.