Provisioning users means creating accounts in one or more applications that are in the users' corporate landscape. Namely, this involves creating an account and pushing out appropriate user profile information and entitlements.

As creating users manually is time-consuming, laborious and poses security threats, to save time and simplify the provisioning process, OpenIAM implements automated provisioning to enable organizations to:

• Create new users in bulk and grant them the right level of access when they join the organization;
• Adjust access rights whenever the user’s position or role in the organization changes;
• Terminate/revoke access when the user no longer works/leaves the organization.

Each of these operations is accompanied by audit logs to provide visibility into when and why changes have occurred.

Provisioning overview

Provisions mainly stands for creating new user identities in OpenIAM and then being able to push them into the target managed systems. The other part, besides being able to create accounts, is being able to modify them. Such modification can be related to a variety of events - it could be the result of job change, a job title change, moving to a different department or different location. A modification can be also related to life changes, e.g. getting married and changing name. Finally, modification means being able to terminate users and cancel access provided earlier.

Provisioning dataflow

Namely, provisioning service does the following:

• Processes the request from the UI/API/Synchronization processes to determine which applications the request concerns.
• Sends the message to the appropriate connector(s):
  • Depending on the Managed System, receives an information package and uses it to update the information.
  • Calculates the package based on the policy map.

This dataflow is illustrated below.

Automated user life cycle overview

The diagram below provides a high level overview of how automated provisioning works in OpenIAM. The diagram also considers that a deployment may have more than one authoritative source. Authoritative sources can be segregated based on a variety of factors including: user type, attributes, etc.

Most Human resources (HR) systems can be integrated with OpenIAM using one of the following approaches:

• API/SDK/Database view - OpenIAM can use either the API, SDK or View provided by the HR system to extract user and organizational information at regularly scheduled intervals: every 1 hr, 4 hrs, 24 hrs, etc. This approach will require the use of an OpenIAM Connector.
• CSV file - CSV file that is generated from the HR system which can be processed by OpenIAM by picking up the files from a network location at regular intervals.

Under this scenario, OpenIAM will do the following to implement automated provisioning:

• Query the source system for new information about employees through the connectors.
• For each new or modified user that is found, the OpenIAM synchronization service will:
  • Map the incoming data to OpenIAM objects.
  • Determine the level of access that a user should have across applications by determining an appropriate birthright access as well other entitlement membership.
  • Pass the object to the provisioning services.
• The provisioning service will then perform the following:
  • Obtain a full list of entitlements based on a person's group or role membership from authorization service.
  • For each application that a user should be provisioned to, the service will:
    • Determine the value of each attribute by using a policy map associated with Managed System.
    • Send a message to each connector with the results of the policy map.
• Connectors will:
  • Communicate with the target system.
  • Apply the changes to the target system based on the message received from the provisioning service.
  • Send a response back to OpenIAM via the message bus.

In the end, OpenIAM will update the identity status and save the actions in the audit logs.

Provisioning Matrix

For each target application that is defined in the planning matrix, check if it can be integrated with a connector to support automated provisioning and deprovisioning. If provisioning can be automated, then define a matrix as shown below to determine which attributes will be updated by OpenIAM and how these values should be generated. The example below is based on Active Directory but should be performed for all of your integrated applications.

Application Name: Active Directory

In this matrix, you should also account for event-based rules which were captured in the joiners/movers/leavers part of the planning matrix. Some aspects of the JML rules may be event based. For example, on a termination, you may disable the account in Active Directory, but you may end-date the account in Oracle EBS. These details are important for both implementation and documentation purposes.

Deprovisioning

Deprovisioning refers to the procedure of revoking an employee's access to your company's systems, applications, and internal data resources. OpenIAM performs deprovisioning in two scenarios:

1. When the user is deleted from OpenIAM using the DELETE operation via API or UI.
2. When the user no longer has active entitlements. An active entitlement is one with a valid end date. When the end date of an entitlement is earlier than the current date or the role is deleted from a user, the entitlement is considered inactive, and OpenIAM sends a DELETE operation to the target system.

If your target system does not allow deleting an object, there are two possible solutions:

1. There might be a default provisioning role that can never be deleted from a user. This auxiliary role helps to keep a user's status as active. It is often named a Default Provision User Role. Users can have groups added and deleted, but this role persists, ensuring the user remains active and cannot be deleted.
2. There is an option you can set on Managed System attributes - ON_DELETE. Its value can be either DISABLE or UPDATE. If set, the DELETE operation will be replaced by the defined operation when sending data to the connector. If the attribute is not defined, the default behavior is to keep the DELETE operation.

Deprovisioning puts an identity into an inactive status. This means that subsequent changes will not be reflected in the target system for the identity that has been deprovisioned. OpenIAM does not send any updates to the connector or the target system for inactive identities.