Once upon a time, if you were an application vendor and you wanted to automate the creating, updating, and deleting of your app’s users, you looked to the standard tools that were available in the on-premise world. Maybe you offered a way to import CSV files. Or, if you were really trying to be “enterprise grade”, you offered a way to sync your on-premise application to your customers’ on-premise LDAP or Active Directory servers.
Unfortunately, in our increasingly cloud-based world, none of these solutions are all that feasible. After all, who wants the risk of opening up their firewall to some strange cloud application just so it can talk to your Active Directory?
So for a lot of cloud vendors, the answer was “user APIs!” This allowed various integrators to build tools to automate user management, and for a while, this was considered the way to go.
Unfortunately, this also meant someone had to code a new integration for every new application. And if you were using a niche application, or you were the developer of an application just starting out, you’d have a hard time convincing an integrator to write a custom tool just for you.
SCIM to the rescue
SCIM stands for System for Cross-Domain Identity Management and while the name sounds like something from a dystopian science fiction novel, the standard itself is quite simple and straightforward to use.
SCIM, at its heart, consists of a set of standardized HTTP endpoints for searching, updating, and deleting user records using JSON formatted data. It also includes standards and guidelines to define how user data should be formatted and sent from an Identity provider to an application (and vice-versa)
The spec is lengthy and goes into great detail about all sorts of things, but the average implementor really just needs to provide a few base capabilities to work with most Identity providers.
And best of all, since these endpoints are standardized, it’s trivial for integrators to write just one SCIM integration that can adapt itself to the particular user payloads any given application requires. By making it easy to integrate identity providers and applications, SCIM does for user provisioning what SAML does for Single Sign-On.
So what does this mean to me?
Whether you’re evaluating an application for purchase or looking into developing features for your application, there are significant benefits to choosing SCIM support.
First and foremost, it’s a standard! This means it will interoperate with any Identity provider that supports SCIM, and you won’t have to look into custom code or tooling in order to get it up and running.
If you’re an application developer, building your app to support the SCIM standard means a larger customer base with less effort. If you’re an application customer, it means more choice in identity providers that can support your chosen applications. It also means no need for expensive integrations, which lowers your total cost of ownership for SaaS apps.
It also means the process of getting users into the application will be vastly streamlined, meaning more productive (or paying) users that much faster.
So now that I’ve sung the praises of SCIM, it’s time to dive a little deeper on what different aspects of SCIM you’ll require for your business needs.
Minimum Viable SCIM
At the very least, the SCIM implementation needs to support a few simple fields to identify users in your application.
Support for the users’ first name, last name, and email address are considered the lowest functional level to claim SCIM support. Additionally, the ability to search for a user by their SCIM username (basically email) is crucial to making sure you can properly find and update existing users in the system.
This is not to say this bare minimum is bad. Quite the contrary!
Take the example of Envoy: Their use case was providing a company-wide visitor directory. So when they choose to roll out SCIM provisioning for their customers, there really wasn’t any reason to do more beyond providing Name, Email and the city any given user was in.
Less is more, more or less
It’s also worthwhile to consider if an application really delivers more value by offering up a large number of provisionable user attributes beyond the basics.
Certainly, there’s always value in an application that allows the users to have some details about their organization or their position within it (especially for larger organizations). And details like who users’ managers are can help with automatically configuring certain workflows and hierarchies within your application.
As an example, Workplace by Facebook uses details like the users’ managers and what office they work from to automatically create a prebuilt community for users based on these attributes.
Additionally, being able to provision a user with a specific role (Admin, creator, read-only, etc.) is valuable if the application offers different capabilities and pricing tiers for different user types.
But don’t get overly impressed with applications that go overboard. While including a user’s profile photo can help with social or sharing applications, in many cases if there isn’t a strong business need to have some user attributes controlled by a central Identity Provider, there’s not much value to including it in the SCIM implementation.
For example, I think our users at OneLogin would have been upset if Slack had chosen the users’ nicknames to be controlled centrally via SCIM rather than leaving that attribute to be defined by their users instead (I like being @notarealdoktor in Slack)
So just because an attribute can be defined by a central Identity Provider, doesn’t mean it should.
Groups
One last thing to consider is if your application has resources and access control over those resources. If this is the case, it’s recommended that you look into support for the SCIM Groups endpoint. This will allow provisioning Identity Providers to make sure that certain classes of users are automatically assigned access to the resources they need in the application on day one and won’t be wasting their time (or an admin’s time) waiting around to be granted access. Plus if governance is of concern to an organization, SCIM Groups let the identity provider control and monitor “who has access to what” within the application.
Go SCIM or Go Home
When looking to the industry as a whole, SCIM is becoming the dominant mechanism to handle user provisioning, whether you’re talking about applications getting their start or unicorns making their move into the enterprise. Orgs like Asana, Envoy, Slack and GitHub all chose SCIM as the right standard when they realized they needed to support larger and larger customers. Even traditional social and sharing platforms like Facebook and Airbnb chose SCIM when they made their leap into more organization-focused offerings. So whether you’re shopping around for an application to support your organization, or you’re wondering how to get your application to the next level of adoption, ask your IT professional if SCIM is right for you. Side effects may include faster onboarding, instant offboarding and increased user productivity.
