About Universal Directory and user profiles
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) delivers rich user profiles and fine-grained control over how attributes flow between applications. This enhancement makes it easier for organizations to create and maintain a single source of truth for its users, enabling new authentication and provisioning scenarios.
With Universal Directory and Profile Editor, you can:
Store rich profiles of user attributes in Okta.
- Customize these profiles with custom attributes.
- Bi-directionally map and move attributes from Okta and applications.
- Transform attributes prior to storing or moving with a powerful expression language.
These capabilities enable you to do the following:
- Keep rich profile information in-sync across HR systems (like Workday), on-premises directories, and applications.
- Provision application user accounts with rich profile information such as roles, managers, or location (which is useful for making access and authorization decisions).
- Construct Okta or 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. usernames from rich attributes and custom expressions.
- Collect and store any type of user attribute, including employee-provided values.
Warning: Universal Directory and the accompanying Profile Editor features are very powerful options. The alteration of profiles and mappings can have unintended effects in downstream apps — be cautious when making changes. Note that when an attribute in a user's profile triggers an update, Okta updates the user's entire profile in the application.
Using Universal Directory
The following explains Universal Directory features, configuration of features, and use-cases. Topics include
- Profiles — Representations of user accounts. Okta supports 2 types of profiles: Okta end user profiles and App user profiles.
- Mappings — Allows you to precisely control the attributes exchanged during provisioning processes.
- Expression Language transformations — Allows you to concatenate attributes, manipulate strings, convert data types, and more.
- Username Overrides — Construct custom Okta user names or application user names.
- Rich SAML Assertions — UD attributes can be sent in 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. assertions and WS-Fed claims.
UD introduces profiles, representations of user accounts. In particular, UD supports two types of profiles:
- Okta End User profile
- App user profile.
The two profile types are used to store rich attributes in Okta and move rich attributes from Okta to 3rd-party apps.
The Okta user profile represents a user in Okta (an Okta account) and is comprised of two parts: base attributes and custom attributes. Okta users can either be end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins., people who use Okta to access the applications they use each day, or users, which is used to refer to Okta administrators who use Okta to administer their orgThe Okta container that represents a real-world organization.'s environment.
Okta has defined 31 default base attributes for all users in an org. These base attributes are generally fixed and cannot be modified or removed. There are two exceptions: First Name and Last Name. These two attributes can be marked as required or optional for Okta-mastered users only. To import users with blank First Name or Last Name attributes, you must first mark the attributes as optional in Okta, otherwise the import will fail.
By default, Okta requires user names to be formatted as email addresses in Okta Universal Directory. Using the Format Restriction control, Administrators can remove the email format constraint from the Username attribute in Okta UD or replace it with a specific set of characters that are allowed. This provides additional control over the format for Okta usernames for all users in an Okta org.
You can only add attributes to the directory profile if they are already in the directory, so Okta first does a schema discoveryAbility to import additional attributes to Okta step to populate the attribute picker. For Okta to discover the attribute, it must be added to an object within the User object hierarchy in the directory: user object, a parent object, or an auxiliary object.
The agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. takes a few seconds to execute the schema discovery. When it’s done you’ll get a list of the attributes that Okta has the permissions to discover in the directory.
You can extend an Okta User profile by adding an attribute to the custom portion of the profile. Base attributes cannot be altered.
Note: When you create custom attributes in the Okta user profile, you cannot use the following reserved keywords for custom attribute names: id, externalid, created, lastupdated, scopeA scope is an indication by the client that it wants to access some resource., status, statuschanged, passwordchanged, syncstate, lastsync, credentials, _links.
An app user profile represents a user in a 3rd-party application, directory, or identity provider (IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta.). The app user profile lists the 3rd-party's attributes that Okta can read and write to (read-only for IdP). This profile is used to control the attributes that Okta pushes to an app or the attributes imported from an app into Okta.
Similar to Okta user profiles, app profiles have both base attributes and custom attributes. Custom attributes for app user profiles differ from those for Okta user profiles. Whereas Okta user profiles can be extended with any custom attribute, app user profiles can only be extended with attributes from a predefined list that Okta dynamically generates. Okta generates the list of attributes by querying the 3rd-party application or directory for supported attributes. That is, each app controls which custom attributes it supports. The Okta profile can only be customized with attributes that the app supports. You cannot create your own custom attribute for an app in addition to those it supports.
Profile mappings allow administrators to precisely control the attributes exchanged during provisioning processes. The two chief use-cases that UD facilitates are
- App to Okta
- Okta to App
App to Okta mappings
In this use-case, organizations typically use a source-of-truth app such as a directory or human resources system. Some organizations might have several sources of truth. Mappings define how attributes from these various sources are imported into the Okta user profile.
The diagram below illustrates the first use case. In the example, 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. (AD) and Workday supply the Okta user profile with attributes (AD provides FirstName and LastName; Workday provides Boss). The diagram illustrates the mapping of givenName and sn to FirstName and LastName (from AD to Okta), and it shows the mapping from managerUserName to Boss (from Workday to Okta).
Okta to App
In this use-case, organizations want to propagate the data in Okta to other applications to provision accounts and update accounts with rich data. This is possible if the Okta user profile has rich attributes and the app in Okta is UD-upgraded.
The following diagram illustrates the second use-case. In the example, Okta sends four attributes to Google. The diagram shows the mappings of four Okta user profile attributes to four Google App user profile attributes.
Expressions allow you to concatenate attributes, manipulate strings, convert data types, and more. Okta supports a subset of the Spring Expression Language (SpEL) functions. Find a comprehensive description of the supported functions under Okta Expression Language. All functions work in UD mappings.
Disclaimer: While some functions (namely string) work in other areas of the product (e.g., SAML 2.0 Template attributes and custom username formats), not all do.
Expressions are useful for maintaining data integrity and formats across apps. For example, you might want to use an email prefix as a username, bulk replace an email suffix, or populate attributes based on a combination of existing ones (e.g., displayName = lastName, firstName).
Okta allows you to handle the most demanding username requirements. Constructing custom Okta user names or application user names with Okta's data and expression language is easy.
Example use cases:
- Construct an Okta username by concatenating multiple imported attributes.
- Create differently formatted user names using conditionals. For example
- If attribute1 = A, then username should end in acme.com. Otherwise, username should end in acme-temp.com.
- Example: email@example.com, firstname.lastname@example.org
- This is useful for distinguishing between different types of users (such as employees vs. contractors).
- Construct app user names from attributes in various sources.
- Enforce a max length by truncating.
The username override feature overrides a previously selected Okta username format or app username format (different per app). When username override is configured, the previously selected username formats no longer apply.
Username override can also be used with Selective Attribute Push to continuously update app user names as user profile information changes. For example, if a user gets assigned to an app with a username of email, and that email subsequently changes, Okta can automatically update the app username to the new email. Prior to this enhancement, 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. had to manually change a user's app username by unassigning the user and reassigning him to the app. This enhancement applies to all apps and is not limited to only apps with provisioning capabilities.
Note: For a list of the characters supported in Okta email addresses, see here.
This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, contact Okta Support.
Overriding the app username
Okta is consolidating where app usernames are configured. Instead of being able to change the app username in the Profile Editor and the app's Sign On tab, you will be able to edit the Okta to App username mappings only on the App's Sign On tab.
For the Okta to App flow, you can no longer override username mappings in Profile Editor
Note: The behavior is not changing for the Active Directory, LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. and SAML Identify Provider apps.
The username mapping displayed in the app's Sign On tab will be the source of truth for the Okta To App flow. Updating the username mapping on Create only or Create and Update will also be managed from the app's Sign On tab.
UD attributes can be sent in SAML assertions and WS-Fed claims. Apps can consume rich SAML assertions and WS-Fed claims to do the following:
- Create rich user accounts in the app
- Update accounts with rich data
- Make fine-grained authorization decisions
Configure Rich SAML Assertions and WS-Fed Claims
Currently, only the App Integration Wizard, Template WS-Fed and Template SAML 2.0 can send UD data.
Note: The Template SAML 2.0 is deprecated.