Provisioning

Provisioning and Authentication are the two main pillars of Okta functionality. Every Okta app or directory connector is considered in the context of those two functions - particularly from the configuration and troubleshooting perspectives. Just as Authentication can be achieved via a variety of methods and protocols (direct auth, delegated auth, SAML, SWA, WS-Fed, OpenID Connect, etc.), Provisioning can similarly be accomplished via multiple strategies.

To begin with, let’s discuss the goal of Provisioning. Okta uses the term Provisioning to encompass a large set of functions. Sometimes, these functions are also collectively referred to as User Management. The set of functions under the Provisioning ‘umbrella’, then, is easily described with the acronym CRUD. This acronym references the common database operations of Create, Read, Update, and Delete. When we borrow the acronym for Provisioning, however, there is a slight modification:

• Create: Create fresh 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: For an application or directory user that is affiliated with or ‘tied to’ an Okta user, update the downstream user’s attributes when the Okta user is updated. Or vice versa, depending on Sourcing

• Deprovision (not typically a Delete): ‘Deprovision’ the application user from the downstream application. This can take many forms; user disabled, user access permissions changed, user license pulled, etc. Confirm specific functionality on an app-by-app basis. 

Sourcing

One final Provisioning concept that deserves mention is the concept of Sourcing. Sourcing defines the flow and maintenance of user object attributes. When a profile is ‘Sourced’ from a given resource (application or directory), the Okta user profile’s attributes are derived exclusively from that resource and, therefore, cannot be edited in Okta. For example, an Active Directory Sourced Okta User has an Okta profile. However, that profile is not editable in Okta by the User or Administrator and derives its information exclusively from Active Directory. 

Okta has implemented a more granular version of this concept, where Sourcing can be applied at the Attribute level rather than only at the whole Profile level. This permits an Okta user Profile to derive portions of its attributes from multiple different Sources. Please consult our Attribute Level Sourcing document for more information.

• Provisioning
• Sourcing
• Universal Directory

Okta provides multiple strategies to perform provisioning operations on downstream applications. These strategies are available for a given app based on what features that Application offers for provisioning connections. The three main strategies used are Agent-based Provisioning, API-based Provisioning, and SAML JIT. 

Agent-based Provisioning 

• An agent (windows service, Linux daemon) installed to the local environment brokers Provisioning transaction requests between Okta and the on-premise resource. 

• Currently Supported Provisioning agents

  • Active Directory

  • LDAP

  • On-Premise Provisioning

    • This agent is generic and intended to connect to any On-Prem resource that can use the SCIM (Secure Cross-domain Identity Management) language. 

    • This typically involves code and a Professional Services Statement Of Work

    • For more information, consult our On-Premises Provisioning Deployment Guide

• This is a good, robust strategy. However, it is limited to on-premise applications. 

API-based Provisioning

• The Okta app connector has been integrated into the Application’s Provisioning API.

• Typically, these provisioning APIs are proprietary.

• Typically, they use the REST model.

• Available functionality from the CRUD feature set is limited to functions published in the App’s API.  For example, some APIs may allow Create and Update but not Deprovision.

• This is the best, most extensible strategy. 

SAML JIT

• SAML is an authentication protocol. However, its functionality can be extended to offer rudimentary Provisioning features via its capacity to include a payload of Attribute Statements in the SAML assertion. 

• This permits Creation and Updates of downstream users. 

• This does NOT permit Imports or Deprovisioning of downstream users.

• The triggering action is a user’s login attempt rather than the Administrator’s assignment action.

  • This limits the flexibility of account creation timing, as accounts in the application cannot be created proactively using this method.

• This strategy can be leveraged to feed the Okta Profile itself via UD mappings. 

• A common use case is for customers with an existing, on-prem IDP (ADFS, for example) but still want to use cloud apps through Okta.

  • Configured using SAML JIT with an Inbound SAML connection

• This is the most restricted, inflexible strategy. However, it can be a lifesaver for the initial deployment of legacy applications. 

• Used frequently with the SAML Template App and the App Integration Wizard.