How to build SCIM user provisioning

February 15 2018

user provisioning scim mulesoft

User management and provisioning have always been tedious and time-consuming tasks for IT professionals. If you’ve seen any of my blog posts before, you’ll know that there are two things I like: exposés in the form of parentheses and removing tedious manual work.

Naturally, this meant I ended up trying to solve user management. One of the first questions I asked when I started addressing this problem was: why hasn’t this been solved yet? And the answer is this: it has already been solved by every organization in their own way. Admittedly, I did the same thing.

The first two iterations of our onboarding and user management processes were short-sighted implementations that were incredibly MuleSoft-specific and fragile. I’m not arrogant enough to think we’ve solved user management (for this series we’ll specifically address provisioning, so I’ll just use that word from here on out), but I think we have a pretty good solution that scales well, is adopted by the industry already, and can be easily extended or customized to every organization’s environment needs.  

To understand the work we’re doing, I need to introduce you to System for Cross Domain Identity Management, or SCIM for short. It’s a mouthful, but it’s relatively self-descriptive. SCIM is a standard model for representing users, groups, and other resources across multiple different applications. It represents the work of a collaboration of industry specialists. In a more concrete sense, the common object looks like this:

user provisioning mulesoft

If you don’t want to read all that (and I don’t blame you), I can summarize it for you. Effectively, the standard object takes roughly 85% of required fields from a smattering of systems and uses those fields. The obvious question that should come up is this: what if what I need isn’t represented?

The most powerful part of the SCIM standard is its acceptance of extensibility. Here at MuleSoft, we use the standard SCIM model and also add our own extension––one we developed in-house. For our own additions to the model, we included things that are necessary to the orchestration of onboarding and off boarding.  We’ve added fields for start date, cut access date, and termination date. Start date allows us to stage meetings, application access, and relevant emails for a new hire before they get in the door.

It is generally helpful for ensuring a smooth onboarding. Cut access date is the day our automation will de-provision systems access, while termination date is the payroll end date. These are all fields which we deemed as relevant metadata to include in our representation of the SCIM model, but they weren’t included originally.


We'd love to hear your opinion on this post

4 Responses to “How to build SCIM user provisioning”

  1. Hello Paul,

    Can you provide some more technical details.

    We are also doing a POC around our Identity management app and SCIM.

    Just wondering if you can share more details ,so that we can get help for our POC

    • Hey Ankit,

      What details would be most helpful? The part two blog post I’ve been working on covers the high level architectural design if that’s what you’re looking for. Otherwise I’d be happy to provide more implementation-based details.

      • Hi Paul,
        Really helpful your post about SCIM.

        We are trying to adopt a similar approach and keen to know about the high level architecture and guidance to follow on SCIM compliant.

        Please could you share further information?


  2. Hi Paul,

    Does Mulesoft has any connector for SCIM APIs? I am asking more in the context of Slack SCIM APIs. Say for example I want to provision user to slack organization using their SCIM APIs. So if connector available then I really don’t need to write the code from the scratch and perhaps I better off the Mulesoft and write a quick python custom application.