Work with custom user types in Universal Directory

Okta supports up to 10 user types: the default Okta user profile plus up to 9 custom user types.

When you create a custom user type, 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. makes a copy of the latest default Okta user profile with the default 31 base Okta attributes. The copy is created with the new user type name you give it (for example, "Contractor"). Once this copy is made, you can then add custom attributes that are relevant to the Contractor user type.

You can customize the 31 base Okta user attributes. Each custom user type can have different attribute settings. You can make some attributes optional or required, select different enum types, and so on. Each user type can map the Okta user profile attributes to different application attributes and add custom attributes. This gives you complete flexibility in your authentication and provisioning scenarios.

Each Okta end user can only have one user type. That is, Jane Doe can only have one Okta user profile type: either the default Okta user profile or a custom user type. You must maintain a one-to-one mapping.

Known issues

These are the known issues for custom user types:

Imported new users are restricted to the default Okta user type.
User type (variable name userType) is one of the 31 attributes in the Okta Base schema. The User type attribute is unrelated to the custom user types feature.
You cannot have two different user types using the same attribute name but with different data types. The data types must match.
If Self-Service Registration is enabled in an orgThe Okta container that represents a real-world organization., all users in the org have their login IDs forcibly mapped to match their email addresses. Forced mapping applies to all User Types in that org.
Unlike property mappings, 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. assertion mappings are not type aware. Okta uses the default user type in all such cases.
- Validation to ensure only authorized admins can edit SAML assertions using sensitive attributes does not account for non-default user types (whose sensitive properties may differ from the default type).
- Properties used in an assertion that only exist for non-default-type users will not have this check applied.
- Sensitive attributes —Properties that are sensitive in the default type, but are not sensitive in some non-default types, will always be treated as sensitive.
- When validating the SAML username EL, Okta considers only how the properties are defined in the default user type, even though custom types may define the properties differently.
Group Membership rules validate the rule only against the default type. This is the case whether you use the "basic condition" UI or the "Okta Expression language" option. In either case, if the expression is not valid for the default type, for example because it references a property that exists only in a custom user type, then the rule can be neither saved nor previewed (even if the user being previewed is of the custom type). If the rule references a property that exists only for the default type and not the custom type, then when it is evaluated for a custom user (for previewing or for determining group memberships) the expression will treat the property as having a value of null.

Group Rules are not executed for non-default user types.

Group 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. assignments are validated against the default User Type. A Group App assignment involving a attribute that is not consistent across multiple User Types will be validated against the default User Type.
Users imported 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. which partial match with existing custom type Okta users can only use User Principal Name (UPN) as Okta username format. When an 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. selects a different Okta username format such as email, sAMAccountName, or other custom appuser properties, the AD property mapping for "login" field is supposed to be changed, but it currently only updates the mapping for the default Okta user type.

The AD settings page allows you to set the Okta login during import flow and AD userName during outbound provisioning flow for the user. In both cases, currently those mappings from this UI would be updated only for the default Okta user type.

The 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. settings page allows you to set the Okta login during import flow and AD userName during outbound provisioning flow for the user. In both cases, currently those mappings from this UI would be updated only for the default Okta user type.

In the LDAP provisioning settings page UI, the section "Okta Attribute Mappings" defines only the mapping between LDAP and the default Okta user profile. In other words, if any of the attribute mappings in this section is updated, it's only reflected in the mapping between the app user profile and the default Okta user profile. If you need to make changes to the mapping between the app user profile and a custom Okta user profile, you need to make such changes in the Profile Editor.

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. settings also do validation if RDN is a valid attribute and that check happens only against the default User Type.

Okta username format— Similar to Active Directory import, if the admin changes "Okta username format" on the LDAP import settings page, the change only applies to the mapping from LDAP to the default Okta user type.
When using the Identity Providers feature, either for 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. Routing Rules or inbound federation, Okta user properties will be interpreted (to determine whether they exist, whether they contain sensitive data, and so on) based only on the default user type. To avoid unintended behavior, be sure that any properties used in IdP policies are configured the same way in all user types.
For inbound federation:
- JIT users are created with the default type.
- When setting up a User Match for inbound federation, the configuration only lists or validates properties in the default type, but matching will be attempted using the actual User Type.
- Mappings are set up automatically from the IdP user or App user to the default type but not any custom types, so unless mappings are manually created nothing will be mapped for those users.
If Okta detects new app templates for either O365 or Sharepoint, existing instances of the app are updated. These automatic updates are currently performed only for app instances associated with the default User Type. If a non-default User Type is assigned O365 or Sharepoint, changes to the templates for those apps will not be applied to those app instances.

Prerequisites

You must be a super or org admin to create custom user types. Once a user type has been created, other admins are able to add properties and mappings, similar to working with the default Okta user type.

You should have a good understanding of how Universal Directory, Profile Editor, attributes, custom attributes, and attribute mappings work, as described in these topics:

Create a new user type

You can create up to 9 custom user types.

Sign in to the Okta Admin Console with super or org admin permissions and click Directory > Profile Editor.
Click Create Okta User Type.
In the Create Okta User Type dialog, complete these fields:
- Display Name - Enter a name for the user type. For example, Contractor or Student. There is a 50 character limit.
- Variable name - Accept the auto-generated value, or enter a value.
Click Save.

The new user type appears in the profile editor. Click Profile to edit the profile attributes.

To change the user type Display name, click Edit, enter a new value, and click Save Profile. You cannot change the variable name .

User type attributes and mappings are managed in the same way as the default Okta user profile.

Map a user type to an application

After you create a user type, you can map it to a specific application to associate the user type attributes with the application.

On the Okta Admin Console, click Directory > Profile Editor.
Select Apps in the Filters list.
Select an application, click Mappings, and select a user type.
Optional. Map attributes. See Map profile attributes
Click Save Mappings or Cancel to return to the profile editor.

Create a user and assign a user type

When you create a new user, you associate them with an Okta user type.

Note

Users imported from applications such as Active Directory, LDAP, Workday, or from a CSV file are assigned the default user type.

On the Okta Admin Console, click Directory > People.
Click Add Person.
Select a user type in the User type list.
Complete these fields:

First name — Enter the user's first name.
Last name — Enter the user's last name.
Username — Enter the user's user name in email format.
Primary email — Optional. Enter the user's primary email if it's different from their username.
Secondary email — Optional. Enter a secondary email to allow the user to access information when their primary email is unavailable.
GroupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. — Optional. Enter the groups to which the user belongs.
Password — Select Set by user to allow the user to set their password, or select Set by admin and enter a password.
Send user activation now - Optional. This check box is available when Set by user is selected as the password option. Select this check box to send a user activation email to the user.
User must change password on first login — Optional. This check box is selected by default when you select Set by admin as the password option. Clear this check box if you do not want the user to change their password when they first log in.

Click Save.

Change the user type

Change the user type to quickly apply new policies and other settings to users. For example, change a user with a contractor user type to an employee user type to apply employee specific policies and settings.

The attribute name and the attribute data type must be identical to allow values to transfer from one user type to another. When the existing attribute name and attribute data type are different in the new user type, the attribute values are not transferred and must be entered manually.

On the Okta Admin Console, click Directory > People.
Optional. Select a user type in the User Type list to filter the people list by a specific user type.
Select a person in the Person & Username column.
Click Change at the top of the user profile screen.
In the Change user to list, select a user type.
Verify the attribute values for the user are correct.
Optional. Update any attribute values that were not transferred.
Click Change user type.

The user type updates at the top of the user profile screen.

Delete a user type

Delete a user type when it's no longer required. A user type can only be deleted when there are no users assigned to it. If there are users associated with the user type when you try to delete it, you'll see a warning that they must be deleted first.

Users can be deleted in Directory > People. You will have to manually deactivate and then delete each user.

Important

Deleting a user type cannot be undone.
The default Okta user type cannot be deleted.

On the Okta Admin Console, click Directory > Profile Editor.
Select the Okta user type you want to delete and click Profile.
Click Delete.
Click Delete to confirm.