Attribute-level mastering

Attribute-level Mastering (ALM) enables you to specify different profile masters for individual user attributes, giving you more precise control over how a user profile is mastered. Without it, all of a user's attributes are mastered by a single 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..

An Okta user's profile master is typically a directory service like 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. or an HR management 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. like Workday. If you use multiple directories or apps, you can prioritize profile masters so that end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using apps to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. are mastered by different sources based on their assignments. Attribute-level mastering takes this a step further, letting you designate different profile masters for different user attributes.

For example, an Okta user may have their profile attributes like first name, last name, and department mastered by an HR system like Workday. With attribute-level mastering, their phone number and email address can be mastered by Active Directory, and their personal email address or preferred display name can be mastered inside Okta and managed by the end user themselves.

Note: Profile masteringMastering is a more sophisticated version of read (import) users. Mastering defines the flow and maintenance of user-object attributes and their lifecycle state. When a profile is mastered from a given resource (application or directory), the Okta user profile’s attributes and lifecycle state are derived exclusively from that resource. In other words, an Okta user mastered by Active Directory (or HR system) has an Okta profile. However, the profile isn’t editable in Okta by the user or Okta admin, and derives its information exclusively from Active Directory. If the lifecycle state of the user in Active Directory moves to Disabled, the linked Okta user also switches to the corresponding lifecycle state of Deactivated on the next the read (import). only applies to Okta user profiles, not app user profiles. For details about profile mastering, see Profile Masters. For general information about provisioning, see Provisioning and Deprovisioning Overview.

Setting up ALM

Using the ALM feature requires that (1) profile mastering is enabled, (2) you have prioritized profile masters on the Profile Masters page, and (3) any desired mappings are specified through 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.(UD) mapping.

The first step in setting up ALM is to enable profile mastering. Use of ALM assumes that more than one profile master is set on the Profile Masters page. In order for these profile-mastered apps to appear under Profile master priority, as shown below, profile mastering must be enabled for those apps.

Enable Profile Mastering for Active Directory

  1. From the Directory drop-down menu, select Directory Integrations.
  2. Click the Active Directory instance.
  3. Click the Settings tab.
  4. Scroll to Import and ProvisioningProvisioning is the enterprise-wide configuration, deployment, and management of multiple types of IT system resources. Specifically, provisioning provides users access to equipment, software, or services. This involves creating, maintaining and deactivating required business process automation objects and attributes in systems, directories, and applications.> Profile Master.
  5. Click Enable.

Enable Profile Mastering for Other Profile Mastering Apps

  1. From the Applications drop-down menu, select Applications.
  2. Choose the app from the list of applications.
  3. From the <app> page, click the Provisioning tab.
  4. From the left-side Settings panel, click To Okta.
  5. Scroll to Profile & Lifecycle Mastering, and then click Edit. Select the Allow <app> to master Okta users check box.

Establish Profile Masters by attribute

The second step of setting up ALM is to establish mastery by attribute. If your profile masters have been successfully enabled, they appear on your orgThe Okta container that represents a real-world organization.'s Profile Editor page as Profile master priority. Each individual attribute's default state is Inherit from profile master, which retains the profile master set for the entire profile.

To change the priority:

  1. From the Directory drop-down menu, select Profile Editor.

  2. On the Profile Editor page, find the source that you want to edit. In its Actions column, click Profile.
  3. Find the attribute that you want to edit. Click the Information icon in the right-hand column.
  4. From the Master priority drop-down list, select one of the following:
    • Inherit from profile master: Picks up the default profile master for the entire profile, as shown in the Profile master priority field.
    • Inherit from Okta: Picks up this particular attribute value from Okta. This attribute value can be edited in three ways: via the user's Profile tab, the Okta API or, if appropriate for end-user modification, by the end user.
    • Override profile master: Overrides the default profile master. Click the Add Master drop-down menu to choose another available profile master. Note that this option does not generally disable the app as a master.

  5. Click Save Attribute.

See below for an example scenario of how this might work with Workday and Active Directory as two profile masters.

Example Profile Master Set
Profile master:
Default master for the entire profile.
Workday, Active Directory
Attribute master: Alternative master for a particular attribute.

3rd attribute: mobile phone = Active Directory

All other attributes: Workday

Example Attributes
First name Workday
Last name Workday
Mobile phone Active Directory
Work phone Workday

Mapping the Attribute on the Profile Mappings Page

The optional third step of setting up ALM is to map the attribute through UD. If you changed an attribute's Master priority to Override profile master, for example, the attribute now has a null value and must be mapped. To map the attribute, do the following:

  1. From the Directory drop-down menu, select Profile Editor.
  2. On the Profile Editor page, find the app instance of the profile master you want to map. In its Actions column, click Mappings.
  3. From the list of attributes on the left, find the attribute (such as Last name) you have chosen to change.
  4. Click the drop-down menu to select a new value for the attribute. Note that ALM only maps from a profile mastered app to Okta. It is not bi-directional.
  5. Click the Save Mappings button to save your choices.

User-added image

If you have selected an attribute that has no mapping from the primary profile master, the attribute has a null value. A value is not pulled from any other master apps in the priority list.

Allowing End-User Edit Permissions

There are some attributes that can be mastered inside Okta and then managed by an Okta adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. or their end users. Although end-users cannot change their primary attributes (such as first name, last name, or primary email), you may want to allow them to add or change attributes like personal email address or preferred display name. These attributes would appear as editable fields on their Settings > Account page.

User-added image

To allow end-user editing of certain attributes, do the following:

  1. From the Directory drop-down menu, select Profile Editor.

  2. On the Profile Editor page, find the source that you want to edit. In its Actions column, click Profile.
  3. Find the attribute that you want to edit. Click the Information icon in the right-hand column.
  4. From the User permission drop-down menu you can choose one of the following options:
  • Hide: Hides the attribute field from the end-user list.
  • Read Only: Prevents the field from being edited.
  • Read-Write: Allows the end-user to change or add information to the attribute field.
  1. From the Master priority drop-down list, choose Inherit from Okta.
  2. Click Save Attribute.

Top