Using Selective Profile Push

This section specifically explores the Selective Profile Push feature for Universal DirectoryUniversal Directory enables you to store an unlimited amount of users and attributes from applications and sources like AD or HR systems. Any type of attributes are supported including linked-objects, sensitive attributes, and pre-defines lists. All of it accessible by all apps in our OIN catalog, over LDAP or via API..

Profile mapping allows administrators to have precise control over the attributes exchanged during provisioning processes. An import from Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. to Okta is one of the more common examples of such an exchange, but it can be applied to any appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. that integrates with Okta. These exchanges center around how attributes are defined and mapped between two elements: the source of data, and the applications to which users are assigned.

Such mappings can be bi-directional. You can begin with a basic Okta user profile, retaining its default attributes, and then map those attributes to the app user profile of a target application. This establishes a 1:1 relationship of data fields between these two entities. Or, you can do the reverse, choosing fields from the target app to map app-related fields to the Okta user. Essentially, you are setting the default attribute mappings for each Okta user or app user profile.

To begin creating this relationship, do the following under the Profile Mappings tab:

  1. From the provided list, find the app or directory you want to map.
  2. Click the Edit Mappings button for the chosen app. The <App> User Profile Mappings page appears.
  3. Note which tab is viewable for the app—<App> to Okta or Okta to <App>.

Selective Profile Push

Along with mapping, the selective profile push feature allows admins to select which attributes are pushed from Okta to an app when a provisioning event occurs. While mapping may be bi-directional, selective profile push is uni-directional, meaning that this data can only be pushed from Okta to a target app.

To successfully use this feature, the following conditions must be true for local (SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully. or SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated.), Provisioning-enabled, and non-provisioning apps:

  • Apps with Provisioning capability must have Update User Attributes enabled under the Provisioning tab for the app. This provisioning feature includes a Do not update Username attribute on user profile check box, which gives you the option to exclude user name updates but allow the update of other attributes.
  • For both app types, pushing user names requires administrator control of the username, never the user. Find this setting under Application > Sign on tab > Sign On Methods.

When the mapping is complete, admins can then decide which attributes are pushed when a profile push occurs. Such events can be set using the arrow drop-down menus.

The options available in the list will vary depending on the scenario of your app configurations. The app type, profile masterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. status, and various states of the app all play a role in which options are displayed.

Mapping Option Displays

Drop-down menu options include the following:

  • Apply mapping on user create and update: This pushes data when a user is created and also when there is a change in their profile.
  • Apply mapping on user create only: This pushes data only when a new user is created, and does not automatically push data when a user profile changes.
  • Do Not map: This removes an existing mapping. See Removing an Existing Mapping below.

NoteOkta does not support partial profile push. During a profile update, Okta pushes the app user's full profile, including attributes that are set to Apply mapping on user create only and Do Not map.

Removing an Existing Mapping

There are two ways to remove a mapping. Simply use the delete button to backspace the entry from the field, or use the drop-down to choose the Do not map option. When successfully deleted, the label of the attribute switches back to Add mapping.