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, please contact Okta Support.

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 what is in essence 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, "Contractors"). 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 or Limitations

These are the known issues or limitations for the Early Access release:

Changing User Type — Converting users into a User Type different from the one they were created with is not supported.
Imports — New users created via imports are restricted to the default Okta user type.
Base schema “user type” attribute — The Base schema in the default user profile – and hence also in the user profile for all custom types – has 31 properties defined by Okta. One of those properties is named "User type" (variable name "userType"). This is a simple string property that customers can use for anything they want. It is unrelated to the new concept of "User type" as introduced by the 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.
Self-Service Registration — 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. That forced mapping applies to all User Types in that org.
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. — Unlike property mappings, SAML assertion mappings are not type aware. Okta simply 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 — 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 can still assign non-default users to 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., but the rules should be limited to properties that exist on all 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. assignment — Group App 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.
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. — Users imported from Active Directory 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.

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. — The LDAP 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.
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. Discovery — When using the Identity Providers feature, either for IdP 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.
Identity Providers — 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.
O365, Sharepoint — 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 help topics:

Create a new user type

You can create up to 9 custom user types.

To create a new user type:

While signed in as a super or org admin, navigate to Directory > Profile Editor in the Admin Console.
Click Create Okta User Type.
In the Create Okta User Type dialog, enter the following values:
- Display Name - The name of the user type. For example, ‘Contractor’, ‘Student’. There is a 50 character limit.
- Variable name - The variable name is auto-generated but can be edited.
Click Save.

The new user type appears in the Profile Editor, where you can edit the profile to customize the attributes as needed.

If you need to change the name of the User Type, you can select the User Type profile, click Edit and change the Display name. The variable name cannot be changed.

Once you have set up the different User Type profile, you can work with the attributes and mappings in the same way as with the default Okta user profile

Mapping Apps to a new User Type

After you have created a new User Type, when you want to map an application to an Okta user profile, you must first select which user profile type to map to.

To map an application to a new User Type:

From the Admin Console, navigate to Directory > Profile Editor.
Locate the application you want to map.
Click Mappings and select the user type you want to map to. The Profile Mappings page is displayed.

From here, you can map the attributes as described in Map profile attributes.

Create a user and assign a User Type

When you create a new user, you will select which Okta user type that user is associated with. Once a user is created, you cannot change their user type.

Note

Users created by importing them from an app such as Active Directory, LDAP or Workday or from a CSV file will be created as the default user type.

An example of selecting a user type when creating a new user.

Delete a User Type

You can delete a custom User Type if it's no longer required, as long as there are no existing users assigned to that user type. 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.

To delete a user type:

Navigate to Directory > Profile Editor.
Select the Okta user type profile you want to delete and click Profile.
Click Delete.
Click Delete to confirm your decision.