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 can be done manually or automatically through technical integration.
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.
Manual provisioning
One of the key benefits of an IGA system is that the process of provisioning or assigning access rights for a user in the target business system is automated. However, the manual provisioning process ensures that you can provision to systems not connected to the IGA system and still monitor and log activities within the IGA solution to meet auditing and compliance requirements. The request is done in the IGA system, while the provisioner, the user, or user group responsible for handling the request, gets a notification to carry out the task which is done manually. Both the requester and provisioner log relevant information in the IGA system.
Best practice IGA system functionality
The requester makes the request directly in the IGA system and the provisioner is sent a manual provisioning task. The provisioner manually performs the actions required to create the assignment between the identity and the resource in the target system and confirms in the IGA system that the task is completed.
Technical process flow
- RoPE determines that an access assignment requires manual provisioning as it does not have an actual desired state.
- RoPE creates a manual provision task.
- An e-mail notification is sent to each person responsible for the manual provisioning who will access the target system and provision access manually.
- The manual provisioning is confirmed in the IGA solution by the provisioner.
- The IGA system updates the actual provisioning claim as being unconfirmed (i.e. the system has not confirmed the actual state itself).
When an updated identity calculation is persisted, RoPE aligns the state of the manual provisioning processes and activities according to the need for provisioning as well as the configuration of provisioners. It means that manual reassignment of the provisioning task is reset.
For more information on manual provisioning, see the Manual provisioning section of the IdentityProcess+ documentation.