About on-premises provisioning

As with cloud-based provisioning, on-premises provisioning uses the SCIM protocol to synchronize user account information between your user store and the applications your end users work with every day.

Note

On-premises provisioning only supports the SCIM 1.1 specification.

Architecture

The on-premises provisioning architecture consists of the following components: Okta, the Okta Provisioning Agent, a SCIM server or custom connectors, and your on-premises applications. As shown in this illustration, all components except Okta are located inside your firewall:

Prerequisites

Note

Implementing on-premises provisioning is only officially supported by Okta when performed by Okta Professional Services. For more information on how to implement Okta-supported on-premises provisioning, contact Okta Professional Services.

To implement Okta on-premises provisioning, you need the following:

  • The Okta Provisioning Agent installed on a Windows or Linux server.
  • A SCIM server to process the provisioning requests sent by the Okta Provisioning Agent. The SCIM server can be the connector you build using the Okta Provisioning Connector SDK or your own program than can process SCIM-based REST calls.
    • The Okta Provisioning Connector SDK package contains an example connector that you can use to test on-premises provisioning and to help you build your own connectors. Do not attempt to use the example connector without modifying it for your deployment.
  • The Transport Layer Security (TLS) v1.2 protocol for Linux and Windows.
  • For high availability on-premises provisioning, you must install an additional Okta Provisioning Agent and SCIM connector on another server. Start the Okta Provisioning Agent, configure your SCIM connector, and enable provisioning on your backup server. If your primary server is unavailable, the Okta Provisioning Agent and the processes run by your SCIM connector continue to operate.

User workflow

When a new user is provisioned from Okta to an on-premises application (for example, a MySQL database) using a SCIM server, this is the typical workflow:

  • An Okta admin creates an instance of an app integration in Okta to represent your MySQL on-premises application.
  • The admin provisions a new user by assigning an Okta user to the MySQL app integration in Okta. Okta creates a provisioning event (create new user). Okta provisioning fails when an application user custom schema contains only array attributes.
  • The Okta Provisioning Agent polls Okta and finds the provisioning event. The Okta Provisioning Agent translates the provisioning event to a SCIM request, making an HTTP POST request to the /Users endpoint of your SCIM server.
  • When the SCIM server receives the POST request made to /Users with a JSON-formatted SCIM representation of the user, it attempts to create that user in the on-premises application.
  • The SCIM server responds to the Okta Provisioning Agent with the SCIM response message as mandated by SCIM protocol.

For enterprises that on-board users using a Human Resource Management System (HRMS) like Workday, Okta provisions and deprovisions users into on-premises applications by using AD as a meeting point. You can configure Okta to manage accounts in your AD instance, and Okta will create and update users in AD based on the user accounts in Workday. This information can then be used by any on-premises application that uses AD as its user store.

Related topics

Typical workflow for deploying on-premises provisioning

Provision on-premises applications

SCIM 1.1 protocol specification