Joiners – Movers – Leavers (JML) Part 1

TL;DR – An overview of the Joiners-Movers-Leavers process and how it can be implemented using Microsoft Azure Active Directory.

When we read about the zero trust model and specifically, the principle of least privileged access, most people think about just the authentication and authorization process. Although that is a huge part, we cannot forget about the processes associated with identity governance that are there to control the specific access those identities possess and how long they have the access. The ultimate goal for any enterprise should be to have one central Identity Governance solution because that is the only way to guarantee an auditable joiners/movers/leavers (JML) process for all employees. That’s the topic of the posts in this series:

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

I grew up in the Caribbean in a house that didn’t have A/C, needless to say it was HOT! When we go back to visit, my sons can’t understand how I survived all those years without A/C. The truth is I didn’t know there were better options. That’s what comes to mind when I see enterprise customers depending on identity providers that don’t provide all the identity governance tools to implement a full JML process. So, this post is an attempt to share what enterprise customers should expect from their identity providers when they refer to identity governance solutions to accomplish an enterprise level JML process. All of which is available with Azure Active Directory.

What is JML?

• Joiners – The joiners process covers the identities that are created for the employees that join the company. The joiners process will also include providing the minimum required access on a variety of applications and services for that user to be able to do their job.
• Movers – The movers process covers the removal and addition of access to the identities of employees that move to a different position, department, location, project, etc. For example, if the employee transfers from the accounting department to the sales department, then they should no longer have access to accounting applications and services, now they should be granted access to sales applications and services.
• Leavers – As the employees retire or are terminated, the access they had should be removed, and their users should be disabled and/or deleted.

A simple goal, an enormous challenge.

The goal of a JML process is to provision, and eventually deprovision, user identities and their privileges to the target applications and services only for users that need it and only for the time they need it. It is a simple goal, but it is an enormous challenge to achieve for all identities in an enterprise. The challenge comes from the number of target applications and services and the number of identities. The higher those numbers are, the higher the complexity. Keep in mind, identities can be the individual user identities as well as their non-user accounts, such as accounts used for administrative tasks.

This complexity is why any enterprise should aim to automate the JML process as much as possible. And that is where a good Identity Governance solution comes in. Partners can then build upon the available solutions to automate the identity governance requirements for enterprises. I’ll cover the details of how that automation can be achieved in the follow-up posts of this series.

What about workload identities?

Even workload identities for machine-to-machine access should be included in some of the identity governance processes, such as access reviews, because they also have permissions associated and therefore we also want to enforce the principle of least privilege on those identities.

A quick note on sources and targets

I mentioned above “target applications and services”, but let’s cover the source first, because for a target to exist, there must be a source. What is commonly referred to as the “source of truth” in identity management is typically an HR system or some directory, where the users are created initially when they are hired as employees or contingent workers. Sometimes you have more than one “source of truth”, for example, if you have one system for employees and another one for contingent workers or if you are getting attributes from other sources. Keep in mind, the “source of truth” is not necessarily the identity provider, in other words, the source of truth is just the initial location of the user data where it exists, where any identity provisioning solution will pull information from about the user and its attributes. Which is not to be confused with the identity provider (IdP), where users authenticate for a SSO solution, because that’s a topic for a different day.

What are the targets then? The identity provisioning solution will get the data from the “source(s) of truth” and based upon the values of those attributes it will then provision and deprovision user identities and privileges to those target applications and services. You can see another over simplified diagram of the solution above. I am not going too deep, but just keep in mind we can also reconcile specific attribute data from target applications back to the provisioning solution, making the targets also sources for specific attributes, because other target applications may need those attributes as well.  

As you can imagine, the values of those attributes don’t remain the same for the entire lifecycle. Attributes such as last name, department, job position, and many others are updated constantly. This is why a central identity management solution integrated with all target applications and services is essential to ensure all those dependent values are updated on target applications as changes occur. And more importantly, the updates of those attributes is what triggers the stage changes and privilege assignment/removal in target applications.

What does Identity Governance include?

A full identity solution should include identity governance and what that includes sometimes can be represented in different ways by different identity service providers, depending on what they offer. Some identity service providers do not provide identity governance solutions and if they do, sometimes they only provide a portion of these. Fortunately, Microsoft, and specifically Azure Active Directory, provides the full range of identity governance solutions required for a successful joiners-movers-leaver process at an enterprise level. Here is a simple list of what an enterprise should require:

• Lifecycle Management – We need to be able to manage both the user lifecycle as well as the access lifecycle. It is very important that we do this from *one* central location, because that is the only way to ensure we know what access a specific identity has on any target application/service. This is also the only way to ensure accurate auditing.
• Provisioning/Deprovisioning (SCIM) – Some applications and services require local identities to be created, so we need to be able to provision those users to the target applications when they are onboarded and then deprovision them once they no longer require access to those applications and services. SCIM (System for Cross-domain Identity Management) is the standard protocol used for provisioning/deprovisioning.
• RBAC / ABAC – Role Based Access Controls and Attribute Based Access Controls. Basically, we need to assign those identities the access that is appropriate for the job they are doing, which can be based on their role, the project they are working on, the location they work from, etc., and only while they need it.
• Entitlements Management – Entitlements are the access permissions that can be assigned to users. They can be in the form of group membership, application roles, OAuth scopes, etc. We need to be able to manage or group these permissions to enforce RBAC/ABAC. By now you know my opinion on groups vs roles and I also gave you some basic info on OAuth and it’s scopes.
• Access Requests and Approvals – Users need to be able to request additional access that was not automatically assigned to them for valid reasons. And that access should be approved by the proper LOB owners or managers, etc.
• Separation of Duties (SoD) – We need to be able to mitigate and reduce risk by isolating privileges that when combined can cause significant errors or intentional fraud. Think of this as ‘checks and balances’. SoD is sometimes referred to as ‘segregation of duties’.
• Certification / Attestation – We need someone to be able to certify or attest that the permissions those identities have at that time are in fact required. This is normally achieved via scheduled access reviews.
• Privileged Access Management – The access to roles that are considered highly privileged should have controls in place that reduce the risks by enforcing JIT (Just-In-Time) access.

I’ll cover how an enterprise can use Microsoft Azure Active Directory security solutions and how partners can build upon them to address all these requirements in parts 2, 3, and 4 in this series.