Automating a GDPR-compliant User Lifecycle with SCIM

SCIM – System for Cross-domain Identity Management – is an open standard to automatically provision and de-provision user accounts and groups. One of the benefits it provides is that it allows a clean implementation of the so-called Joiner-Mover-Leaver process.

In this blog post, we’ll explain the basics of SCIM and how it can help you automate your user and group management, while ensuring GDPR compliance. We’ll also share a hands-on example of SCIM in action, and discuss its support across different Identity Providers like Azure Active Directory and Google Cloud Platform. Whether you’re a meshcloud customer or just interested in learning more about SCIM, keep reading!

Automating Joiner-Mover-Leaver Process: Understanding the Pitfalls and Solutions

Before we delve into SCIM, let’s first take a step back to understand the problem we’re trying to solve. If you’re not familiar with the Joiner-Mover-Leaver process, here’s a quick overview: When a new employee joins a company, they may later move to a different department or move up the hierarchy after a promotion. Eventually, the employee may decide to seek new opportunities elsewhere or retire and leave the company. The Joiner-Mover-Leaver process refers to these three important phases during an employee’s lifecycle.

Let’s examine each phase from the perspective of Anna Admin, the sysadmin of our hypothetical company. Anna is responsible for ensuring that every employee has the necessary access permissions to perform their job. We’ll go through each phase step-by-step and explore the challenges that arise if Anna doesn’t have an automated system for provisioning and deprovisioning.

Joiner

The joiner phase describes the employee onboarding process, which typically involves entering the new user into an Identity Provider (IdP) system. Many companies use an IdP such as Azure Active Directory (AAD) or Active Directory. However, entering the employee into the IdP is only the first step; often, the user needs to be entered into multiple external systems as well. Single Sign-On (SSO) doesn’t always solve this problem since the external system may require the user to exist before they attempt to log in.

For example, an HR system needs to store the employee’s salary and address before their first day. Manually entering user information into each external system is not only a manual burden, but also prone to errors, such as confusing first and last names. If Anna Admin onboarded a new colleague named Sun Kim, she might accidentally enter her as Kim Sun in another system.

Mover

Suppose John Doe, an employee of our fictional company, has moved from Customer Support to Sales. John already has access to an externally hosted business intelligence tool that provides all sorts of analyses. He used to require this tool to evaluate the success of Customer Support, for example, to see how long a customer who contacted Customer Support needs to wait on average until they receive a reply. Now, in his new department, John needs this tool to evaluate which products are sold how often. However, when his colleague sends him a link to a sales analysis, John receives an "Access Denied" page because no access permissions have been adapted in the business intelligence tool since John changed to Sales.

John sends an email to Anna Admin, asking her to grant him access so he can access all sales analyses. However, if Anna Admin receives dozens of such requests each day, she most likely won’t make any effort to verify if John indeed needs this new access permission, nor will she make sure to remove the access permissions that John no longer needs. As a result, John’s access request will be granted simply because he asked for it, without any permissions being revoked. This is a clear violation of the Principle of Least Privilege, which states that an employee should only obtain the minimal set of access permissions they need to do their job.

Leaver

Suppose John Doe has left our fictional company, and Anna has removed John from the IdP. However, what about all the external systems that John had access to, such as the business intelligence tool? Without automation in place, Anna would have to manually remove John from each and every system. This is a tedious and time-consuming task that is likely to be neglected, as most sysadmins have better things to do than keep track of what external system is used by whom. As a result, John’s personal data may still be present on external systems where it is no longer needed. Unfortunately, this is a violation of the GDPR.

Personal data shall be: […] accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);

SCIM Basics: Simplifying Cross-domain Identity Management

Let’s understand the basics before we explain how SCIM comes to the rescue to address these problems. SCIM stands for System for Cross-domain Identity Management. It’s an open standard that describes how to exchange information between systems to keep identity-related information up-to-date.

In SCIM terminology, information is exchanged between two parties: The client and the service provider. In most scenarios, the client is an IdP such as Azure Active Directory (AAD). The service provider, on the other hand, is the external system that requires knowledge of the identities and must be informed of identity-related changes.

The client sends requests to the service provider to inform it of existing identities and any identity changes, so that the identities are mirrored at the service provider. Similarly, all existing groups are stored in the IdP and replicated from the client to the service provider. If a user becomes a member of a group or leaves a group, a request is sent from the client to the service provider.

In summary, requests are sent from the client to the service provider to allow the service provider to keep an up-to-date representation of all users and groups, while the client remains the Single Source of Truth for all questions related to Identity Management.

It is worth highlighting that with SCIM, every action is initiated by the client. This provides a number of advantages if you compare it with other approaches. For example, some applications synchronize user identities and groups from your IdP by directly accessing an LDAP server.

An LDAP server usually cannot be reached over the internet, so this requires putting holes in your firewall, which your CISO may not approve of, or setting up a VPN or other means of secure network communication between your IdP and your service provider, which can be time-consuming.

With SCIM, on the other hand, no data is sent from the service provider to the client, unless it is a response to a previous request sent by the client. Therefore, no changes need to be made to your firewall as long as the client has internet connectivity.

Hands-on SCIM: How SCIM Works in Real-World Scenarios

To see a real world example between two systems that support SCIM, we have connected AAD via SCIM to AWS IAM Identity Center to synchronize identities from AAD to AWS. In SCIM-terminology, this means AAD is the client, while AWS IAM Identity Center is a service provider. We won’t go into the details about each and every request, but we will outline a simple workflow to get a better grasp of how SCIM works in general.

Let’s revisit the joiner phase that we have previously described, with Anna Admin being in charge of the IdP of our fictional company. In our real world example setup, AAD is now the IdP, so if a new employee joins the company, Anna would enter this employee into AAD. After we entered a new user – John Doe – we observe that AAD first sends a GET request to the following URI to test if the username already exists:

/scim/v2/Users?filter=userName+eq+%22john.doe%40company.com%22

AWS responds with the following JSON document:

{
    "Resources": [],
    "itemsPerPage": 0,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 0
}

The important part is only that the Resources array is empty: No users with the username code>john.doe@company.com were found. With that information, AAD now understands that it can create this user without creating a conflict with an existing user, so it subsequently sends a POST request with the following JSON payload:

{
    "active": true,
    "displayName": "John Doe",
    "externalId": "john.doe",
    "meta": {
        "resourceType": "User"
    },
    "name": {
        "familyName": "Doe",
        "formatted": "John Doe",
        "givenName": "Doe"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
    ],
    "userName": "john.doe@company.com"
}

{
    "active": true,
    "displayName": "John Doe",
    "externalId": "john.doe",
    "id": "d09c197c-d0f1-70f4-e128-dce284dbd937",
    "meta": {
        "created": "2023-03-23T15:48:31Z",
        "lastModified": "2023-03-23T15:48:31Z",
        "resourceType": "User"
    },
    "name": {
        "familyName": "Doe",
        "formatted": "John Doe",
        "givenName": "John"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "john.doe@company.com"
}

{
    "Operations": [
        {
            "op": "Replace",
            "path": "name.familyName",
            "value": "Smith"
        },
        {
            "op": "Replace",
            "path": "name.formatted",
            "value": "John Smith"
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

Role-based access control is a simple and established principle where we decide what a user is authorized to do based on their group memberships. It’s used by many applications, including meshStack. Whatever your company is using as IdP (AAD, plain Active Directory, or something else) your IdP most likely already provides the ability to create groups and put employees into the groups they belong to.

Let’s revisit the problem during the mover phase that we described earlier, where John asked Anna for additional access permissions after he changed from Customer Support to Sales, and Anna granted those permissions without revoking other permissions that are not required anymore. How does SCIM help in such a scenario?

First, Anna does not need to touch any external systems. She needs to adapt John’s group membership in the IdP only, which is a system she is already very familiar with. But we also need to keep in mind that SCIM only replicates existing information, so if the Principle of Least Privilege is already violated at the IdP, SCIM is not going to magically solve it for us.

However, in many companies, the IdP is already under the scrutiny of auditors, so ideally, our fictional company already has a process in place that ensures that the Principle of Least Privilege is maintained at the IdP.

Some companies might even have automation in place that ensures that as soon as HR moves an employee from one department to another, group memberships are automatically added and revoked based on the department and job title. In that case, employing SCIM for group synchronization can ensure that the Principle of Least Privilege is maintained not only in your IdP, but in all external systems as well.

User Deactivation & Deletion with SCIM: The Final Phase of the Joiner-Mover-Leaver Process

Let’s look at the final phase of the Joiner-Mover-Leaver process and see how SCIM helps us when an employee leaves the company. Once the user is removed from the IdP, you want that user deactivated or removed on all external systems. Both are possible via SCIM.

Deactivation

Looking at the SCIM RFC from the perspective of a service provider, there’s a lot of freedom to decide what user deactivation means for your application. User activation and deactivation is controlled with the active attribute, which is described in the RFC as follows:

The definitive meaning of [active] is determined by the service provider. As a typical example, a value of true implies that the user is able to log in, while a value of false implies that the user’s account has been suspended.

Although not explicitly stated in the RFC, it is, however, important that a user can be re-activated after it has been deactivated. This is the behavior that IdPs such as AAD expect: For example, an AAD admin could disable a user in AAD, resulting in an SCIM deactivation request. Once the user is re-enabled in AAD, this will trigger another SCIM request to set this user to active.

Deletion

SCIM mandates that a service provider must provide the ability to delete users and groups, but the RFC again leaves some freedom as to how deletion is implemented:

Clients request resource removal via DELETE. Service providers MAY choose not to permanently delete the resource […].

This is more than just an implementation detail if you care about GDPR-compliance. The GDPR mandates that:

Personal data shall be: […] accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);

So, using SCIM supported systems in your company is unfortunately no guarantee that your offboarding process is compliant with the GDPR. In fact, there are examples of applications that support SCIM and have decided to implement only a non-permanent user deletion via SCIM. One such example is Slack: Their API documentation explicitly lists it as a shortcoming that users cannot be permanently deleted via SCIM, but only deactivated.

At meshcloud, we care about GDPR-compliance, and we want to enable an automated and GDPR-compliant offboarding process. This is why user deletion via SCIM is permanent at meshStack: Once a user is deleted, it cannot be restored. If you’re a customer at meshcloud, and you would like to know more about user deactivation and deletion with SCIM, you can find more details in our public documentation.

SCIM Support Across Different Identity Providers: Pros and Cons

In this blog post, we have focussed on AAD, since this is the IdP used by most of our customers. From our experience, SCIM support in AAD is very mature and relatively easy-to-use. Setting up SCIM synchronization between AAD and meshStack (or any other application) is described in our public documentation and takes just a few steps.

Google Cloud Platform, on the other hand, does not seem to support custom SCIM implementations at the moment. There are a select few applications that are officially supported by Google to be used as an SCIM service provider, but you can’t just point Google to a custom endpoint URL that then receives SCIM requests.

Similarly, AWS does not seem to provide the possibility to synchronize their identities via SCIM to a service provider. Synchronizing identities from another IdP such as AAD via SCIM to AWS IAM Identity Center is well documented and relatively easy to set up, but the other way around, i.e, using AWS as your primary IdP and synchronize its identities via SCIM to a service provider, does not seem to be supported at the moment.

Automating User Management with meshStack and SCIM

Having all your users and groups synchronized automatically between your IdP and external systems like meshStack not only makes your life easier, it can also be a very clean solution from a compliance perspective. But keep in mind that applications that claim to support SCIM do not always do so in a way that guarantees full compliance with GDPR.

With our recent release 7.169.0, our SCIM support was extended to have the entire user lifecycle, from onboarding to offboarding, fully automated and GDPR-compliant with AAD. If you use AAD, feel free to head over to our public documentation and try it out.