3 Reconciliation and Provisioning Processes

This chapter discusses the processes that are involved during target resource reconciliation and provisioning, and trusted source reconciliation.

If you want to configure target resource reconciliation and provisioning, then see the following sections for the respective processes involved:

If you want to configure trusted source reconciliation, then see the following section for the process involved:

3.1 Target Resource Reconciliation

The target resource reconciliation process involves the following steps:

  1. A change is made on the target system.

    A change on the target system can be the creation, modification, or deletion of an account on the target system. This event is called a reconciliation event.

  2. The change on the target system is detected and communicated to Oracle Identity Manager by the reconciliation APIs.

    The manner in which the change is communicated to Oracle Identity Manager depends on whether reconciliation is configured according to the push model or the pull model.

  3. A reconciliation event record is created for each target system record that is communicated to Oracle Identity Manager.

  4. Events for which matches with existing OIM Users are found are forwarded for further processing.

    Events for which matches cannot be found can be further processed by an administrator. The administrator can manually map these events to their corresponding OIM Users, and these events are then forwarded for further processing.

  5. The reconciliation engine checks if there are values in each event for the attributes that are designated as mandatory attributes in Oracle Identity Manager. Events in which there are values for all the mandatory attributes are forwarded for further processing. Events in which there is no value for a mandatory attribute are sent to an administrator. The administrator can manually enter values for these attributes, and these events are then forwarded for further processing.

  6. For each event, the process matching rules (defined by the key field for reconciliation matching) are evaluated to find the provisioned resource that matches the event.

  7. If a match is found, then the match is added to the list of provisioned resource matches that have been found up to this point.

    If no match is found, then the reconciliation owner matching rule (that is, the reconciliation rule) is evaluated to determine the owner (OIM User) of the event in Oracle Identity Manager. If a match is found, then the match is added to the list of owner matches that have been found up to this point.

  8. After rule evaluation, each event is in one of the following states:

    • Match found with a provisioned resource in Oracle Identity Manager.

    • No match found with a provisioned resource in Oracle Identity Manager, but match found with an OIM User .

    • Match found with neither provisioned resource nor OIM owner.

    Depending on the state of each event, reconciliation action rules are applied to it. If the action rule specifies assignment, then the event is assigned to an administrator or administrator group. If the action rule specifies linking, then the event is forwarded for linking.

  9. If the event is a Delete event, then:

    1. The provisioning process for the resource instance is canceled.

    2. The status of the resource is set to “Revoked.”

    3. The “Reconciliation Delete Received” task is inserted.

    If the event is not a Delete event and if a match was found with a provisioned resource, then:

    1. The data of the process form of the provisioned resource is updated.

    2. The “Reconciliation Update Received” task is inserted.

    If the event is not a Delete event, and if no match was found with a provisioned resource but an owner match was found, then:

    1. A new instance of the resource is created for the owner.

    2. The process form for the provisioned resource is populated with the data from the event.

    3. The “Reconciliation Insert Received” task is inserted.

3.2 Provisioning

Note:

Direct provisioning has been used to illustrate the provisioning process. Some of these steps are actions that an Oracle Identity Manager administrator performs on the Oracle Identity Manager Administrative and User Console. The remaining steps are provisioning-driven and take place automatically.

To provision a resource to an OIM User, you log in to the Oracle Identity Manager Administrative and User Console and follow the procedure to provision a resource. When you enter values in the page that contains the process form details and click continue, the provisioning process is started.

"Provisioning Resources" contains the procedure to perform direct provisioning for an OIM User.

The following is the sequence of steps for the direct provisioning process in Microsoft Active Directory:

  1. The IT resource for the target system is linked with the resource object that you select for the provisioning operation. When you submit the provisioning data, this data and the parameter values of the IT resource are passed on to the process task. For example, information from the AD Server IT resource and the UD_ADUSER process form is passed on to the Create User process task.

  2. The process task passes the information to the adapter with which it is associated. For the example described in the preceding step, the Create User process task passes the information to the adpADCSCREATEUSER adapter.

  3. The adapter passes the request to the Microsoft Active Directory API.

  4. The target system API creates the user account on the target system and returns a response code to the adapter, which carries the code back to the process task. Depending on the response code it receives, the process task displays the outcome of the provisioning operation on the Oracle Identity Manager Administrative and User Console. The message is also recorded in the application server log file.

3.3 Trusted Source Reconciliation

The trusted source reconciliation process involves the following steps:

  1. A change is made on the target system.

    A change on the target system can be the creation, modification, or deletion of an account on the target system. This event is called a reconciliation event.

  2. The change on the target system is detected and communicated to Oracle Identity Manager by the reconciliation APIs.

    The manner in which the change is communicated to Oracle Identity Manager depends on whether reconciliation is configured according to the push model or the pull model.

  3. A reconciliation event record is created for each target system record that is communicated to Oracle Identity Manager.

  4. Events for which matches with existing OIM Users are found are forwarded for further processing.

    Events for which matches cannot be found can be further processed by an administrator. The administrator can manually map these events to their corresponding OIM Users, and these events are then forwarded for further processing.

  5. The reconciliation engine checks if there are values in each event for the attributes that are designated as mandatory attributes in Oracle Identity Manager. Events in which there are values for all the mandatory attributes are forwarded for further processing. Events in which there are no values for even one mandatory attribute are sent to an administrator. The administrator can manually enter values for these attributes, and these events are then forwarded for further processing.

  6. For each event, the reconciliation rules are evaluated to find the matching OIM User for the event.

  7. If a match is found, then the match is added to the list of matches that have been found up to this point.

  8. After rule evaluation, each event is in one of the following states:

    • Match found with an OIM User.

    • No match found with a provisioned resource in Oracle Identity Manager, but match found with an OIM User.

    • Match found with neither provisioned resource nor OIM owner.

    Depending on the state of each event, reconciliation action rules are applied to it. If the action rule specifies assignment, then the event is assigned to an administrator or administrator group. If the action rule specifies linking, then the event is forwarded for linking.

  9. If the event is a Delete event, then:

    1. The OIM User is deleted.

    2. All related deprovisioning activities are carried out.

      This depends on the target systems and their settings for data integrity. For example, if a user is deleted, then the connector must ensure that the user's group memberships at the target system are deleted as well.

    3. The “Reconciliation Delete Received” task is inserted.

    If the event is not a Delete event and if a match was found with an OIM User, then:

    1. The data of the OIM User is updated.

    2. The “Reconciliation Update Received” task is inserted.

    If the event is not a Delete event if no match was found with an owner entity, then:

    1. A new instance of the entity (OIM User) is created.

    2. The attribute fields for the entity is populated with the data from the event.

    3. All related provisioning activities are carried out.

    4. The “Reconciliation Insert Received” task is inserted.

  10. If the task is automated, then the response code of the task is set to “Event Processed” and any related provisioning actions are initiated.