Mastering Okta Identity Management
Universal Directory Implementation
Okta's Data Model
Okta's identity storage begins with the Universal Directory (UD). At its core, the UD is built on three primary object types: Users, Groups, and Devices. Users are the individual identities, representing employees, customers, or partners. Groups are collections of users, typically organised by department, project, or access level. Devices are the endpoints, like laptops and mobile phones, used to access your applications.
This structure provides a comprehensive view of who is accessing your resources, what their roles are, and from where they are connecting. Unlike a traditional, rigid directory, the UD is designed to be a flexible, central hub for identity data from any source.
Customising User Profiles
The default Okta user profile includes standard attributes like first name, last name, and email. However, most organisations need to store more specific information. This is where the Profile Editor comes in. It allows you to extend the base user schema with custom attributes, such as employeeID, departmentCode, or officeLocation.
Once you define these attributes, you need to populate them. Data rarely arrives in the perfect format. You might need to combine a first and last name to create a username, or convert a country code to a full country name. This transformation is handled by the Okta Expression Language (OEL), a powerful tool for manipulating attributes during data mapping.
// Example: Creating a username from first and last name
String.toLowerCase(String.substring(user.firstName, 0, 1) + user.lastName)
// Example: Setting a 'region' attribute based on country code
user.countryCode == "US" ? "North America" :
user.countryCode == "GB" ? "Europe" : "Other"
Integrating External Directories
Few organisations start with a blank slate. Most have existing identity stores, typically Active Directory (AD) or another LDAP-compliant directory. Okta integrates seamlessly with these systems using lightweight agents. For AD, the Okta AD Agent is installed on a domain-joined server. This agent communicates with your domain controllers and securely proxies authentication requests and data synchronisations to the Okta cloud.
This connection enables two primary functions: directory import and directory integration. An import is a one-time or scheduled pull of users and groups from AD into Okta. Integration, on the other hand, creates a real-time link. When a user authenticates, Okta can delegate that authentication request directly to AD. This means users can continue using their familiar AD passwords to access cloud applications through Okta.
| Feature | Directory Import | Directory Integration |
|---|---|---|
| User Source | Users and groups are copied into Okta. | Users and groups are linked from the external directory. |
| Authentication | Handled by Okta. | Delegated to the external directory. |
| Password | Managed in Okta. | Managed in the external directory. |
| Use Case | Migrating fully to Okta as the master. | Co-existing with an on-premise directory. |
The choice between these methods hinges on a critical strategic decision: determining your system's Source of Truth (SoT).
The Source of Truth is the authoritative system where user identity data is created and managed throughout its lifecycle.
There are three common models:
- Okta as SoT: Users are created and managed directly within Okta. This is common for modern, cloud-first companies or for managing external identities like partners and customers.
- External Directory as SoT: Systems like Active Directory or LDAP remain the master. Okta imports users and groups from them, but all changes (new hires, terminations) are made in the on-premise directory first.
- HR System as SoT: An HR platform like Workday or SAP SuccessFactors acts as the master. When an employee is hired, their profile is created in the HR system, which then provisions an account in Okta, which may in turn create an account in Active Directory.
Choosing the right SoT depends on your existing infrastructure and business processes. An HR-driven model is often the most robust for employee identities, as it ties the identity lifecycle directly to the employment lifecycle.
What are the three primary object types at the core of Okta's Universal Directory?
An organisation needs to store an employee's unique departmentCode in their Okta profile. Which tool should an administrator use to add this custom attribute to the user schema?
With the Universal Directory configured and connected to your sources of truth, you have established the foundation for all access control. The next step is to use this rich identity data to build security policies.