IAM Explained: Identity Provisioning & User Lifecycle Management

In the previous article of this series, I was talking about IGA (Identity Governance & Administration) and the core elements of #iga , which are

1. Identity Provisioning
2. User Lifecycle Management
3. Access Governance

In this article, I will dig deeper into the details of the first two capabilities.

Identity #provisioning is at the very core of IGA. The market segment even had been named Identity Provisioning in the early days of IGA.

Identity Provisioning cares for distributing changes from source systems such as the HR system to target systems such as Microsoft Active Direcory, SAP, and many others.

For doing so, there are two main (groups of) components required:

1. The "control plane" which manages the Identity Provisioning activities
2. The #connectors which enable the communication between the IGA system and the target systems

The provisioning system must keep track of where which accounts reside. If a user "Martin" is created, accounts for Martin might become defined in various target systems. The provisioning system must know where these reside. For doing so, it either uses an external directory or (more commonly) keeps tracks in an internal directory. These directories de facto serve as meta directories. They may contain a lot of detail information and attributes on accounts or just meta information.

The provisioning systems coordinates synchronization, but also commonly supports the so-called reconciliation. Reconciliation reads information about the current account status from target systems and compares this with the information maintained by the provisioning system. It can identify discrepancies and fix these. Such discrepancies could for instance occur when a local administrator of a target system manually creates accounts, instead of relying on automated provisioning.

Provisioning systems also commonly support some matching capabilities that help to identify whether users already exist.

They use the connectors to connect to target systems. #scim (System for Cross-Domain Identity Management) has established as the standard here. Instead of creating custom connectors per target system, SCIM enables to use a standard interface. Thus, the effort for creating and maintaining connectors is significantly reduced. SCIM is increasingly supported, specifically by SaaS applications.

In the past (and to a certain extent still today), connectors were the Achilles' heel of identity provisioning, for two reasons:

1. The effort for creating and maintaining connectors was and is high for vendors. While standard connectors for common systems such as Microsoft Active Directory or several of the SAP target systems are widely available, connectors to lesser popular applications might be lacking and must be created manually.
2. Not every system provides good and easy to use interfaces for identity provisioning connectors. Ideally, there is a REST API that can be used. Factually, some systems completely lack such interfaces.

The reality is that in most organizations, many of the target systems are not connected to the provisioning system. The main reasons are a lack of connectors and the effort required to create custom connectors. It is strongly recommended to at least have an interface to an #itsm (IT Service Management) system for creating tickets for manual fulfilment of change requests in target systems that are not automatically provisioned. That way, there is full control about the changes triggered by joiner, mover, and leaver processes.

The second element of IGA I'd like to cover in this article is User Lifecycle Management. This is the workflow part which factually overlaps with the Access Governance service, the latter also relying on workflows.

Here, the various IGA processes are defined and executed. While we commonly talk about JML for Joiner/Mover/Leaver, these factually are way more processes and workflows such as the ones for role management, for exception handling, for recertification, for access request and approval, and many more.

HR or other sources (HR might be limited regarding the scope of identities covered, with its primary focus on employees) commonly trigger the joiner process. The IGA system then cares for creating accounts in defined systems based on policies/rules and assigning entitlements (commonly via group and role memberships) to these. Ideally, this birthright provisioning is highly automated, with 90% or more of the accounts and entitlements being created right here based on policies (and yes, I'm aware of the fact that many organizations are far from these 90% automation... - happy to discuss how to get closer to this).

Further accounts and entitlements then will become assigned via manual access request and approval that again can trigger provisioning processes.

There is much more to tell about this part of IGA, but focusing on essentials here. The next article will look at the #accessgovernance part of IGA.