You use attribute mappings to control what attributes are exchanged during the provisioning process. These are the two types of attribute mapping:
The data that is exchanged during provisioning is determined by the attribute definitions and how the attributes are mapped between the source of the data, and the applications to which users are assigned.
Attribute mappings can be bidirectional. You can map default Okta user profile attributes to app user attributes, or from the app to Okta user profile attributes.
The app request workflow cannot be used with apps that have required personal attributes.
With this type of attribute mapping, multiple or single instances of directories or human resources applications are used as a source of truth. Attribute mappings define how attributes from these sources are imported into the Okta user profile.
In this diagram, Active Directory (AD) and Workday supply the Okta user profile with the FirstName, LastName and Boss attributes. The AD attributes
sn are mapped to the Okta attributes
LastName and the Workday attribute
managerUserName is mapped to the Okta attribute
With this type of attribute mapping, data is pushed from Okta to other applications to provision and update user accounts.
Mapping attributes that aren’t in the Okta user profile, such as those from different sources like LDAP, is not supported. Mappings are applied when the Okta user profile is updated, and not when the source profile is updated. To ensure mapped data is consistently sent to target applications, the expressions used in profile mappings should only include Okta user profile attributes.
In this diagram, Okta sends four user profile attributes to four corresponding user profile attributes in Google.
Attributes are not updated or reapplied when the user’s group membership changes.