The identity provisioning service provides for configurable and audit-capable propagation of identities and their attributes between identity stores owned or managed by a customer.

Companies prefer to use one identity provider, a service or on-premise software, as the single source of truth for all corporate identities. If other services or software require their own dedicated identity store, the preference is to propagate identities from the single source of truth to those other dedicated identity stores. This significantly reduces the possibility of introducing inconsistencies in identities and their associated data across all systems.

The identity provisioning service creates connectors that permit near real-time updates from PingOne Directory to other identity stores and periodic propagation of updates from other identity stores into PingOne Directory. Other dedicated identity stores can also propagate their updates into PingOne Directory through the API requests of the PingOne SCIM service.

You can build as many connectors as required to achieve your required use cases. For example, an existing Human Resources application is the source store for high-level identities. It propagates its core identity data to PingOne Directory via SCIM, either through an inbound SCIM connector or through the SCIM service’s API. PingOne Directory provides additional identity attributes. PingOne Directory propagates appropriate identities, with needed attributes, through outbound connectors to Slack and Zoom so that new users can quickly use those productivity apps!

An identity propagation configuration consists of:

Identity propagation configuration revision instances are snapshots of the state of the plan, store, rule, and mapping entities of a configuration taken at a point in time. A new configuration revision can be created at any time, capturing the current state of those resources.

The API supports the configuration of one or more identity propagation plans on behalf of a customer environment. After configuration, the identity propagation plans are executed in response to changes on watched identity stores. Over time, identities become consistent across all watched (source) and unwatched (target) identity stores defined in an identity propagation plan. Identities are created, updated, and deleted as specified by each plan.

Creating, modifying, or deleting an identity propagation plan can occur at any time with no effect on the contents of the source identity store, which is the PingOne directory. All actions taken by the can be audited after-the-fact. The contents of identity stores can be modified at any time by external parties, such as administrators or other automated systems. The identity propagation system detects and logs any modifications.

The system monitors the availability of identity stores identified in the plans. If an identity store becomes unavailable, plan execution is paused until the store becomes available again.

Identities from managed identity stores are never duplicated or stored in full by the identity propagation system or its component services. Change summaries and change orders containing some attributes of identities are stored briefly during the provisioning process and can be present in audit logs.

Putting it all together

To better understand how all the components of propagation work together, see the use case Create a Workday propagation connection. This is the most complicated propagation use case because it has additional steps unique to Workday (clearly identified in the use case). Propagation connections with other identity stores use all steps not marked as applicable only to Workday.

Use cases