This article details the functionality of Profile Sourcing, including popular applications that have the functionality in Okta.
- Profile Sourcing
- Provisioning
- Okta Integration Network (OIN)
- Universal Directory
- Lifecycle Management
A profile source is an application that acts as the source of truth for user identities. Once enabled from the Provisioning tab of the app or directory, it appears in the profile source list on the Profile Sources page. If an external profile source is not identified, Okta is the source for all profiles.
If more than one profile source is listed on the Profile Sources page, Admins can prioritize them so that user profile attributes can be sourced by different systems based on their assignments. At any given time, there can only be one profile source for a user's profile.
Profile sources are powerful tools that can help Admins manage a user's entire life cycle (creation, updates, and deactivation). For example, use Workday as a profile source to send user creation, updates, and termination events from Workday to Okta.
Below are some of the apps and directories that allow profile sourcing:
- Active Directory
- BambooHR
- G Suite
- LDAP
- NetSuite
- Namely (built by ISV)
- Salesforce
- SuccessFactors
- UltiPro
- Workday
To determine whether an Application supports Profile Sourcing, see the following Use Case on the Applications Catalog page:
In addition to this, applications that support profile sourcing will also have "Attribute Sourcing" list under the application's "Provisioning" section:
Admins can enable Profile Source and Update User Attributes for the same application, which lets Admins push Okta to App profile mappings to the highest priority profile source. This is beneficial when Admins want to sync attributes such as an email address and phone number from downstream applications back to the profile source. However, Admins may lose data if an app designated as a profile source can also receive profile updates from Okta.
Before Admins enable Profile Source and Update User Attributes for the same app, consider the following:
- Unwanted profile pushes - Okta updates can overwrite the values of unmapped attributes in an app, even if that app is the highest-priority profile source. For example, if the cn attribute is not mapped from Active Directory to Okta, and Admins have configured Active Directory for Profile Source and Update User Attributes - Okta applies the default mapping to cn.
- Overwritten IdP-sourced attributes - Okta to app updates can overwrite attributes sourced by another identity source. There is no partial push option.
- Race conditions - Okta can overwrite an updated attribute in an identity source before other updates are pushed back to - Okta. For example, consider a scenario in which a user's first name and last name are imported into Okta from a directory, but the user's email address is imported into Okta from an app. If the user's last name changes in the directory before the applicable email address update is made in the app - Okta could push the new name and the old email address.
NOTE: Using a profile source necessitates a clear distinction between newly imported users and updates to current Okta users. Okta uses matching rules to maintain a link between the profile source and Okta to prevent conflicts. See User Creation & Matching in Provisioning and Deprovisioning.
If Admins wish to make an application a profile source, the following steps can be performed:
- In the Admin Console, click Applications > Applications.
- Optional. Enter the application name in the Search field.
- Click an application name in the list of applications.
- Click the Provisioning tab.
- Select To Okta in the Settings list.
- Scroll to Profile & Lifecycle Sourcing, click Edit, and select the Allow <app> to source Okta users check box.
- Click OK in the Enable Profile Sourcing dialog box if it appears.
- Optional. Select what should happen to the user when they are deactivated in the app:
- Do Nothing: Prevents activity in the app from controlling the user life cycle. This still allows profile source control of attributes and mappings.
- Deactivate: This default setting allows the user to be automatically deactivated when deactivated in the target app.
- Suspend: This setting allows the user to be automatically suspended when deactivated in the target app.
- Optional. Select what should happen to a user when they are reactivated in the app:
- Reactivate suspended Okta users: Allows an admin to choose if a suspended Okta user should be reactivated when they have been reactivated in the app.
- Reactivate deactivated Okta users: Allows an admin to choose if a deactivated Okta user should be reactivated when they have been reactivated in the app.
- Click Save.
