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, are easily described with the acronym CRUD. If you’re familiar with database management, this acronym will be familiar as referencing 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 in order 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 Mastery
- 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.
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.
- 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
- 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.
- The Okta app connector has been integrated to 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 API's may allow Create and Update, but not Deprovision.
- This is the best, most extensible strategy.
- 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 the timing of account creation, 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.
- Common use case is for customers who have an existing, on-prem IDP (ADFS, for example) but still want to use cloud apps through Okta.
- 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.
One final Provisioning concept deserves mention: the concept of Mastery. Mastery defines the flow and maintenance of user object attributes. When a profile is ‘Mastered’ from a given resource (application or directory), the Okta user profile’s attributes is derived exclusively from that resource and therefore cannot be edited in Okta. For example, an Active Directory Mastered Okta User has an Okta profile. However, that profile is not editable in Okta by the User or Adminstrator and derives its information exclusively from Active Directory.
Okta has implemented a more granular version of this concept, where Mastery 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 Masters. Please consult our Attribute Level Mastering document for more information.