Provisioning

From an Omada Identity perspective, to provision something means to create it in a target system.

In case of an account assignment, the act of provisioning results in the creation of a new account object in the target system. In case of a permission assignment it (typically) results in adding the permission to the account (or adding the account to the permission) in the target system.

To deprovision something means to delete it in the target system.

In case of an account assignment, it results in the deletion of the account object in the target system. In case of a permission assignment, it (typically) results in the removal of the permission from the account (or removing the account from the permission) in the target system.

RoPE and OPS use provisioning claims as a temporal signal that a provisioning action or deprovisioning action has been completed. The claim is only valid until the fulfillment has been confirmed by an ODW import. As long as the claim is valid, it affects the provisioning status because RoPE uses this claim as an "unconfirmed" actual state. It is caused by the fact that RoPE does not have a more recent actual state from ODW. A valid provisioning claim is displayed in the assignment explorer as a "Reason" of the type "Unconfirmed actual." Deprovisioning claims are not displayed as an explicit reason.

Provisioning dependencies

Provisioning dependencies make it possible to specify on a resource that RoPE should run provisioning after the provisioning of another specific resource has been completed. You can also specify on a resource folder that provisioning of all resources in that folder should be delayed until the provisioning of another specific resource has been completed.

This is relevant for systems that use accounts from another system for authentication, for example Microsoft Exchange that provisions mailboxes to Active Directory accounts. In this case, RoPE cannot provision a User mailbox before the Active Directory account exists.

RoPE uses the provisioning status values, Delayed provisioning and Delayed deprovisioning, to signal delayed provisioning and delayed deprovisioning.

OPS and manual provisioning tasks are not created for account and permission assignments that have one of the two status values.

A CRA gets the status Delayed Provisioning if:

• The assigned resource depends on another resource for which the identity does not have a CRA at all.
• The assigned resource depends on another resource for which the identity has a CRA but no actual state reason.
• The CRA is a permission assignment (CPRA), and its calculated account assignment (CARA) is in another system (possible if there is trust between the systems) and the CARA does not have an actual state reason.

A CRA gets the status Delayed Deprovisioning if another CRA with an actual state reason exists for a resource that depends on the assigned resource.

Configuring provisioning dependencies

Resource data objects include a setting called Provisioning depends on that refers to a resource. Calculated resource assignments to the first resource depend on the provisioning of the referred resource.

Resource folder data objects have a single value reference property called Provisioning depends on that refers to a resource.

Calculated resource assignments whose provisioning depends on another resource are not provisioned until the referred resource has been provisioned.

If both the resource data object and the resource folder data object refer to a resource in the Provisioning depends on property, the value of the resource data object overrules the value of the Resource folder.

Example

In this example, you have registered and imported from a system for which you specify to use Manual provisioning as the provisioning method. You choose this under the Enable Provisioning task on the system's page.

The system has a resource named Write. The target system does not allow an assignment for Write to be provisioned before another assignment for the resource Read has been provisioned.

To make Omada Identity respect that, configure the dependency in a setting on the resource called Provisioning depends on.

An identity now makes an access request for the two resources.

The identity gets a CRA for Write that is Pending Provisioning.

The CRA for Write has the provisioning status Delayed Provisioning because you cannot provision it before Read has been provisioned.

Because of that, the provisioner is only asked to provision the Read assignment to begin with.

Afterwards, the provisioner gets another task to provision the Write assignment. This is because the provisioning status has now changed in the CRA for Write from Delayed provisioning to Pending provisioning.

Deprovisioning tasks are created in opposite order to the provisioning tasks.

Skipping provisioning

You can configure resources to specify that assignments for the resource should not be provisioned even if provisioning is enabled on the system level.

You can do this by enabling the Skip provisioning setting on the Resource data object. If you enable the Skip provisioning setting, RoPE calculates the provisioning status OK for the calculated resource assignments for that resource.

This setting is enabled, for example, in the Exchange Mailbox Option resources in the Exchange integration feature.