SCIM: Building the Identity Layer for the Internet

In 2014, a working group reached consensus for v2.0 of SCIM — a simple yet powerful standard that more and more large digital organizations are beginning to adopt for cross-domain identity management. Just last month, the Internet took a leap forward in standardizing SCIM specifications, now officially published by the Internet Engineering Task Force as RFC7643 and RFC7644.

In this piece we introduce the SCIM protocol, track the progress of the standard, and identify new resource retrieval standards documented in the September 2015 RFC. Guided by IETF working group contributor Erik Wahlstrom, we’ll introduce the basics of SCIM, and identify lessons learned from the design of the SCIM API that have directed further iteration of the project as a whole. In future articles, we will dive deeper into using the SCIM standard to create user accounts on a virtual service.

What is SCIM?

Enterprises are extremely distributed — applications and data are sent and stored all over the place, from cloud servers, parter systems, to internal servers. Throughout a scattered environment, it’s easy to lose control of where the data is. But as data privacy becomes more and more a heated issue, regaining control of identity is a top priority.

Enter SCIM. SCIM (System for Cross Domain Identity Management) has been created as a way to standardize how companies create, update, and delete identity data — a standard for the life cycle management of online identity by allowing a standard method for exchanging identity to other partners or systems.

SCIM is a lightweight provisioning protocol that specifically defines two things:

Scheme: the identity profile could be a user, group, machine, or other resource entity. SCIM defines what those resources look like and how they are structured.
Protocol: the method of transport; how do we send user data to different systems?

Standardized by the Internet Engineering Task Force (IETF), contributors to the project include companies like Nexus, Oracle, SailPoint, Salesforce, Google, Cisco, Ping Identity, and Microsoft. It seems like the SCIM standard is getting the hype and involvement it deserves, indicating a roadmap to future ubiquity.

Watch Erik Wahlstroem of Nexus Technology and SCIM IETF working group

Use Cases for SCIM

There are two distinct systems involved in using SCIM: a system that is either creating or reading user identity data, and the system that stores this data. In a world of competing regulations, you often need varying levels of trust between parties. In Germany, for example, in order to send personal information you need user consent every time you do it. SCIM doesn’t go down this rabbit hole, not concerning itself with legal obligations. It assumes the right to share information is existent between the two players. Assuming this trust has already been established between the two entities using other security methodologies, SCIM can be used to exchange identity information for a variety of use cases. Here are three examples:

1: Synchronization Across Corporate Systems

What happens when a new employee joins a corporation? An HR manager will likely add a new user profile to their database. As it would be tedious to create redundant profiles in all cloud and internal systems, the company ideally wants to automatically synchronize data across all systems. Standardizing identity control with SCIM enables a method for creation, and removal of universal identity data.

2: On-Demand Provisioning

For companies using CRMs like Salesforce, you end up paying a monthly fee per each account. But what happens when employees leave, sales teams change, and thus the amount of users altered? SCIM could help companies save money by instigating on-demand provisioning, wherein when a Salesforce account is created, a SCIM account is created. When a user quits, the account can easily be removed, and operational costs decreased.

3: Inter-Clouds Transfer

Have you ever had difficulty switching between accounts in Google apps? Even more troublesome is transferring existing company assets between various cloud platforms. Suppose a company wanted to migrate from Office 365 to Google — there really isn’t an easy way to do this. If all providers supported the SCIM standard, however, user information could be moved about more easily.

Schemas & SPML Comparison

Prior to SCIM there have been attempts at standardizing cross domain identity control. SPML, developed by OASIS, has been an open protocol since 2003. However, it is heavy, XML based, and doesn’t define a schema — meaning that every time data is sent, systems on the other end don’t really understand what the resource is supposed to look like.

SCIM, on the other hand, allows developers to create their own schemas, and defines two off the bat: user and group. Standards have also been made to extend this within the core specification with the enterprise user schema, to cater to an IT manager with unique privileges. SCIM also has a schema that defines schemas, enabling systems to speak with one another to find out what resources they support, and what they look like. A meta schema helps determine the capabilities of each server: can you create users? Filter users? This is a big difference between SPML and SCIM.

Securing-the-API-stronghold-blog-post-CTA-01

The SCIM API

SCIM is handled via a REST-based API for provisioning, change, and de-provisioning — all of which lie outside the realm of OAuth and SAML. With the rise of web APIs and microservices, SAML, has been deemed by some as too heavy with it’s verbose XML. SCIM rather calls for authentication and access tokens in compact JSON, passed via HTTP headers.

The SCIM API can be tested from a command line, is cURL friendly, and firewall friendly. Wahlstrom notes that REST-based APIs can be proxied through a firewall, and can easily implement standard security using SSL and TLS certifications and data encryption. SCIM standard doesn’t necessarily define an authentication method but recommends OAuth2.

The SCIM core schema mentions 5 unique endpoints:

Resource	Endpoint	Operations	Description
User	/Users	GET, POST, PUT, PATCH, DELETE	Retrieve/Add/Modify Users
Group	/Groups	GET, POST, PUT, PATCH, DELETE	Retrieve/Add/Modify Groups
Service Provider Configuration	/ServiceProviderConfigs	GET	Retrieve the Service Provider’s Configuration
Schema	/Schemas	GET	Retrieve a Resource’s Schema
Bulk	/Bulk	POST	Bulk modify Resources

Reformatted from SCIM API documentation

For example, posting to the /Users endpoint can be used to create a user. In this case, a developer would receive an HTTP 201 successful response that includes an ID — a unique identifier created for each resource that also obtains its own URL. This acts as a permalink, allowing a developer to access the same user information from a GET response where the user info is always stored, regardless of future edits. Increasing discovery with the help of schemas is essential for partner-partner communication.

As user storages can be huge, SCIM specifications include features like filtering, paging, and sorting. Next, we’ll explore some other features and see why these were standardized by the SCIM working group.

Features

As Wahlstroem describes, they have gone through many iterations of SCIM. After many decisions and voting (which often involved group humming to reach a consensus) the IETF working group reached standards for the following feature sets. Takeaways from these design lessons could definitely apply to other development scenarios, so take heed.

Extensibility: In developing a standard, you can’t please everyone — there will inevitably be outliers that request for extended features outside of the project scope. To this end, the SCIM team embraced the 80–20 rule, only specifying the most common 80% of use cases. Focusing on delivering core cases is extremely essential for designing standards, as 20% percentile corner cases often take the bulk of your time and are far harder to implement.
Versioning of API and Schema: SCIM standards place the versioning of the API in the URL. This means that a record of versioning is tracked for each specific resource, providing a historical record for all identity entries. Though the team considered versioning in the header, they opted for URL to retain the permalink for permanent profile discoverability in a single fixed location. This makes it easier to understand for implementers and easy to track records with /v1/Users/username, /v2/Users/username, and so forth.
Weak ETags for Versioning of User Data: ETags are used a lot in the web world, like for caching within your browser, for example. In SCIM, the HTTP function of weak ETags are used to track the versioning of specific files. Weak ETags allow systems to hold the same data even across different formatting options. Such may occur if a new developer using a variant JSON parser changes the placement of two different attributes. Weak ETags allow systems to know that data is the same.
Error Handling: Defining error codes can be a tedious process, but it is worth it to increase the satisfaction of the end developer. Users don’t like staring blankly at a 404 Error message — error responses need to be machine readable and human readable, which is why the group defines robust, detailed error codes in the SCIM specification.
HTTP Method Overloading: Some firewalls and proxies don’t like all HTTP verbs — often, servers and client servers don’t support DELETE or PATCH calls. So, SCIM standard solves this by allowing a POST call to be made with an X-HTTP-Method-Override: DELETE function — an important key in allowing requests to be made to different services with varying verb support.

Conclusion: Progressing a Needed Standard

A huge benefit of SCIM is that customers can own their own data and identities. Simplified Single Sign On (SSO), is an important step for the cloud and increasing interoperability across systems. SCIM is an important step for privacy, and, according to Wahlstroem , a vital step in building an identity layer of the internet. According to the latest Request for Comments, “SCIM’s intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.”

Stay tuned for further articles, in which we will dive deeper into using the SCIM standard to create user accounts on a virtual service.