Joiners – Movers – Leavers (JML) Part 2

This post is part of a series.

Part 1 – The basics
Part 2 – Lifecycle Management and Provisioning/Deprovisioning (this post)
Part 3 – RBAC/ABAC, Entitlements Management, and Requests & Approvals
Part 4 – Separation of Duties, Certification / Attestation, and Privileged Access Management

Lifecycle Management

Lifecycle Management targets the creation of users and their privileges as they join, move, or leave an organization. It must be done from a central solution, in order to ensure accurate reporting and auditing, and because that’s the only way to ensure there are no lingering accounts or access when they are no longer needed.

User Lifecycle – Provisioning / Deprovisioning of users

User identities go through various main stages in the lifecycle. The typical stages are non-existent, active, disabled, and finally deleted. There are also possible transitions between those stages, as depicted below:

Each of these transitions is triggered typically by either the initial record creation on the “source of truth” or by updates to the attributes of the existing user records. This is the first component of the JML process, the provisioning and deprovisioning of users. When those transitions occur within the sources of truth, the provisioning solution receives that data and processes the equivalent required transitions on the target applications. For example, the hiring of a new user in an HR solution, will trigger the creation of a user in various target applications, including the main enterprise directory, an email solution, etc. A transition that triggers the creation of all users on a specific target application is sometimes referred to as a “birthright” application, because ALL users get access to that application, one example is an email target application, because typically all users require an email account.  Some applications will only trigger the creation of users based on a specific attribute, for example, only users that are hired for the finance department will need accounts created on a financial application.  A provisioning automation solution can use the value of ‘department’ to trigger the provisioning of users on a target application.

Some target applications do not require the users to exist at all in the target application to be able to grant access, because they use a type of federation that doesn’t require a local user to exist. You can see an example of that setup on my AWS Single Account Access blog post. You still need the user to exist on the identity provider (IdP), but they don’t need to exist on the target application. The privileges granted to the user are tracked on the identity provider only. This is a great setup because it eliminates the need to update users on those target applications.

However, the simple provisioning or deprovisioning of users on target applications does not constitute a full JML process. Normally when a user is provisioned to a target application, birthright or otherwise, they can be assigned “default” privileges, but most users will need different privileges, so default privileges are not always sufficient. That’s where the access lifecycle explained below comes into play.

Access Lifecycle – Provisioning / Deprovisioning of privileges

In the same way that users are provisioned and deprovisioned on the target applications, when required, they also may need specific privileges assigned and removed as they move through the lifecycle.  For instance, an engineer that is part of a cloud implementation team will need access to specific accounts and specific resources within that account. In her first job role, she may initially need privileges such as Key Vault Contributor for a specific vault for a specific project. Later on the same engineer moves to a 2nd position in a different department, and she will no longer need the access to the previous account, but now needs a different level of access on different subscription, such as Azure Kubernetes Service RBAC Admin.  This is the second component of the JML process, the provisioning and deprovisioning of privileges.

This second component of JML in itself has two main options:

• Some privileges can be automatically assigned and removed as the user moves through the lifecycle.  The automation of the assignment and removal of these privileges can be achieved using existing tools, such as Logic Apps that communicate with the Microsoft Graph API to trigger assignment of access packages. More on that on part 3.
• Other privileges have to be requested because they require additional approvals.

Azure Active Directory & SCIM

As mentioned on part 1, SCIM (System for Cross-domain Identity Management) is the standard protocol used for provisioning and deprovisioning. Azure AD supports SCIM protocol for a large number of applications and services, including well known enterprise solutions , custom apps, and on-prem applications.

For example, on my demo tenant I configured a few solutions to provision users and their roles to target applications. This example is for ServiceNow, where I configured provisioning and the job runs every 40 minutes.

So, when I assign Patti to ServiceNow with the role of User in Azure AD:

The user is then provisioned automatically to the ServiceNow instance with that role:

And when I remove Patti from the assigned users/groups, she is also disabled in ServiceNow:

I will expand on how roles for various applications can be packaged together for specific users in the follow-up posts on this series.

I have only scratched the surface of what is possible with Azure AD and SCIM. Azure AD App Gallery continues to increase the number applications and services that support provisioning of users and roles as our partners continue to develop their own SCIM connectors. Additionally, solutions for on-prem applications are also being used that support SCIM protocol.

The ability to use the SCIM protocol for all types of provisioning requirements is a huge Azure AD benefit for performance, reliability, and security reasons. Unfortunately, I have seen what happens when identity providers create their own solutions to provision users that do not follow the SCIM protocol and the results are often unpredictable, which in turn cause unnecessary headaches for IT Operations, Governance, and Security teams.

Update September 2022 – Microsoft released a new service called Lifecycle Workflows that helps with the automation of tasks based on the Joiner-Mover-Leaver cycle. I will write a separate post on this topic soon.

In the next post, part 3, I cover the concepts of RBAC/ABAC, Entitlements Management, and Requests & Approvals.