Part 1: How to build SCIM user provisioning

February 15 2018

0 comments 0
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 offboarding.  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.

In the next part of this blog series, we’ll look into how we used this standard model to build an orchestrated user provisioning system that is API-led and, as a result, highly flexible.


We'd love to hear your opinion on this post