SCIM Provisioning: The Pros, the Cons, and Everything You Need to Know

Today’s businesses increasingly look to SaaS applications to power productivity and growth. But with highly sensitive customer information and corporate intellectual property often locked in these apps, managing access in a secure and compliant manner is critical. To ensure that only the right users can access the right resources, and that new and departing users are quickly onboarded and offboarded, user provisioning and deprovisioning are key. This is how user accounts and profiles (including permissions) are created, managed, and deleted across the corporate IT environment, including in its SaaS apps.

The best way to reduce costs, prevent human error, and improve security and scalability is to automate the process. This is where SCIM comes in.

What is SCIM?

SCIM is the System for Cross-domain Identity Management: it’s an open standard designed to automate user provisioning across domains, using JSON and REST. Before it was introduced, administrators usually had to deal with proprietary APIs, which added time and complexity to the provisioning process. Previous attempts to create a standardized model for managing and sharing identity data between identity providers and service providers (SaaS vendors) included the Directory Services Markup Language (DSML) and the Service Provisioning Markup Language (SPML). Both failed, as most administrators felt that they were too complex and bloated.

How does SCIM provisioning work?

SCIM automates the exchange of user identity data from client (for example, a corporate identity and access management system or a third-party identity provider) to service provider (for example, a SaaS vendor). SCIM defines a standard schema for exchanging identity data items (like usernames) with SaaS applications. And it provides a REST API that performs CRUD (Create, Read, Update, and Delete) actions for managing data through the entire identity lifecycle. The idea is that SCIM automatically syncs, via a REST API, any actions taken on the client side (such as an admin creating, updating, or deleting an account) with the service provider side (SaaS vendor) — so they’re both aligned and up to date.

What are the alternatives to SCIM?

SAML (Security Assertion Markup Language): While SCIM is focused on user provisioning (authorization), SAML is an XML-based open standard that focuses on authentication. It can be used to enable single sign-on (SSO). SAML could technically allow admins to auto provision user accounts with dedicated permissions, but that’s not the case with every SAML implementation. In addition, it provides attributes to the SaaS tool only when a user logs in. It will not help with deprovisioning; rather, it merely prevents user access to the SaaS app.

Public APIs: Various cloud providers, including AWS, now allow admins to provision user accounts via their own public APIs. But every API is different, which means that this method gives admins no standardized and automated way to manage user provisioning across a large number of disparate SaaS vendors.

What are the benefits of SCIM?

SCIM was designed to provide a secure, standardized way to automate provisioning across domains without the need for expensive custom integrations and management of proprietary APIs. Synchronization between identity provider and SaaS provider should keep operational costs down and support rapid onboarding and offboarding. SCIM automated provisioning also requires the use of single sign-on (SSO). All of this should help organizations to improve security, reduce operational costs, ensure compliance, and free up IT teams to focus on other tasks. However, there are hidden downsides.

What are the downsides of SCIM?

Although SCIM is usually portrayed as a useful tool for auto provisioning, there are several rarely documented drawbacks: SCIM can add extra costs due to punitive SaaS vendor pricing, coverage is by no means universal, and implementation is far from easy. The experience can also differ vastly from vendor to vendor, which can significantly diminish the value of SCIM to a business. Let’s explore these in more detail:

The SSO tax: SSO allows a user to access multiple SaaS apps via a single set of credentials and a single identity provider. In organizations with more than four or five employees, SSO is a crucial tool for IT admins who need to manage identities across multiple discrete apps.

There’s just one problem: SaaS vendors often charge a premium for customers to be able to connect their SSO provider. This “SSO tax” can make SSO prohibitively expensive for smaller organizations. Unfortunately, SaaS vendors often treat SCIM the same way they treat SSO: as an enterprise feature that they charge a premium for access to. For SCIM to work, SSO is required.

The result is that, in some cases, customers must pay two to four times the base product price for access to an “enterprise plan,” simply to use SCIM and SSO.

Sample 2022 prices:

• Linear: $10 per u/m basic; $15 per u/m SSO price
• Slack: $6.25 per u/m basic; $11.75 per u/m SSO price
• Calendly: $12 per u/m basic; $25 per u/m SSO price

The complexity of implementing SCIM: SCIM may be marketed as a streamlined way to support automated provisioning, but that doesn’t mean it’s quick and easy to implement. Unlike OAuth (which requires a simple login for each user account), SCIM integration demands a manual setup. Depending on the volume of SaaS apps in use in an organization, this could take some time.

Disappointing coverage: SCIM is often described as being supported by most SaaS vendors. That’s not necessarily the case. This fact, combined with the prohibitive pricing associated with the SSO tax, can mean that, despite its promise, SCIM is truly operational for only a small share of SaaS apps in use. That means more manual labor for IT — exactly the thing SCIM was meant to prevent.

A disparity in experience among different SaaS vendors: Buyers should also beware that the SCIM functionality they get from one SaaS vendor may not be the same as that of another. Although it’s a standard, there’s not always a standardized experience.
In a best-case scenario, SCIM allows IT admins to create new user accounts, define what permissions each user should have, and receive user lists including permissions through the SCIM API. At the opposite end of the spectrum, a SaaS vendor will allow SCIM only to create a user account, making it no more useful than SAML. Worse still, they may not receive the full user list via the SCIM API. That would be disastrous for security and compliance. SCIM is meant to enhance transparency, but often that’s not the case. It’s a lottery, depending on which SaaS apps you’re using.

A new and flexible alternative to SCIM: Integration accounts

A new approach gaining traction in the auto provisioning space involves utilizing “integration accounts.” To automate access to a SaaS tool, a dedicated service account is set up and linked to the access management provider. This account then acts as a bridge between access management systems and the individual SaaS apps. By utilizing a mix of RPA and available APIs, the access management provider is thus able to automate:

• Adding and deleting user accounts
• Changing user permissions
• Synchronizing user lists and user permissions

The value of this approach lies in its flexibility. It doesn’t rely on the availability of public APIs, or how it is implemented — meaning that it can be used across a large range of SaaS apps. This makes it particularly attractive to SMEs of 50 to 200 employees that use a wide variety of SaaS applications — many of which may not offer access to public APIs. But it’s also useful for larger enterprises, which often rely on SCIM but find their efforts thwarted by the large number of applications that don’t cover the standard.

Final thoughts on SCIM Provisioning

SCIM is often touted as a secure, standardized way to automate provisioning across domains without the need for expensive custom integrations and management of proprietary APIs. However, there are some significant but often overlooked downsides. Most critical is an “SSO tax” — SaaS vendors levying a hefty surcharge for companies that want to use SCIM and SSO. Users may also be disappointed by the time-consuming manual setup, lack of SaaS coverage, and inconsistent SCIM functionality they get from each SaaS app. For many admins, integration accounts offer a more cost-effective and user-friendly way to add and delete user accounts, change permissions, and synchronize user lists and permissions.