Overview of Okta Provisioning

Okta provisioning encompasses creating, reading, updating, and deprovisioning user accounts in downstream applications. Administrators perform provisioning operations using agent-based provisioning, application programming interface (API) based provisioning, or Security Assertion Markup Language (SAML) Just-In-Time (JIT) provisioning. Sourcing defines the flow and maintenance of user object attributes from a given resource.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Provisioning
• Sourcing
• Universal Directory

What are the core functions of Okta provisioning?

Okta uses the term provisioning to encompass a large set of functions, often referred to as user management. These functions follow the Create, Read, Update, and Delete (CRUD) model, with a slight modification for deprovisioning.

Review the following list to understand the core provisioning functions in Okta.

• Create: Create new users in the downstream application or directory based on values derived from the Okta user profile and Okta group assignment.
• Read: Import users from the downstream application or directory to match them to existing Okta users or to create new Okta users from the imported application or directory users.
• Update: Update the downstream user attributes when the Okta user updates, or vice versa, depending on sourcing.
• Deprovision: Deprovision the application user from the downstream application. This action takes many forms, such as disabling the user, changing user access permissions, or pulling a user's license. Confirm specific functionality on an application-by-application basis.

Review the following diagram to understand the provisioning flow to an application.

Sourcing Defines the Flow and Maintenance of User Object Attributes

When a given resource, such as an application or directory, sources a profile, the Okta user profile attributes derive exclusively from that resource, and administrators cannot edit them in Okta. For example, an Active Directory sourced Okta user has an Okta profile, but the user or administrator cannot edit that profile in Okta because it derives its information exclusively from Active Directory.

Okta implements a granular version of this concept, allowing sourcing at the attribute level rather than only at the profile level. This permits an Okta user profile to derive portions of its attributes from multiple sources. Consult the Attribute Level Sourcing document for more information.

What strategies are available to perform provisioning operations?

Okta provides multiple strategies to perform provisioning operations on downstream applications based on the features the application offers for provisioning connections.

Agent-Based Provisioning Connects Okta to On-Premises Resources

An agent installed in the local environment brokers provisioning transaction requests between Okta and the on-premises resource. This strategy is robust but limited to on-premises applications.

Review the following list of supported provisioning agents.

• Active Directory (AD)
• Lightweight Directory Access Protocol (LDAP)
• On-Premises Provisioning: This generic agent connects to any on-premises resource that uses the System for Cross-domain Identity Management (SCIM) language. This typically involves code and a Professional Services Statement of Work. Consult the On-Premises Provisioning Deployment Guide for more information.

API-Based Provisioning Integrates the Okta Application Connector Into the Application Provisioning API

API-based provisioning is the most extensible strategy. These provisioning APIs are typically proprietary and use the Representational State Transfer (REST) model. The application API limits the available functionality from the CRUD feature set to published functions. For example, some APIs allow create and update functions but do not allow deprovisioning.

SAML JIT Extends Authentication to Offer Rudimentary Provisioning Features

SAML is an authentication protocol, but its functionality extends to offer rudimentary provisioning features via its capacity to include a payload of attribute statements in the SAML assertion. This strategy is the most restricted and inflexible, but it assists with the initial deployment of legacy applications. Administrators frequently use this strategy with the SAML Template App and the App Integration Wizard.

Review the following characteristics of SAML JIT provisioning.

• Permits the creation and updates of downstream users.
• Does not permit imports or deprovisioning of downstream users.
• Triggers via a user login attempt rather than an administrator assignment action.
• Limits the flexibility of account creation timing, as Okta cannot proactively create accounts in the application.
• Leverages Universal Directory mappings to feed the Okta profile.
• Supports use cases where organizations have an existing on-premises identity provider, such as Active Directory Federation Services (ADFS), but still want to use cloud applications through Okta.
• Configures using SAML JIT with an Inbound SAML connection.