System For Cross Domain Identity Management (SCIM)

Introduction

Over the last decade, the world has moved towards cloud-based operational environments. Albeit the process of conversion from on-premise to cloud is rather slow, any such motive needs to be done carefully. Identity provisioning is an important aspect to consider because data security breaches can cause serious harm.

System for Cross-Domain Identity Management (SCIM) comes into play as an emerging open standard for making identity provisioning in cloud-based applications and services easier, cheaper, and faster. WSO2 Identity Server supports SCIM 1.1 and SCIM 2.0 for identity provisioning.

What is Identity Provisioning?

In simple terms, identity provisioning is the creation, maintenance, and deactivation of user accounts, in one or more systems or applications, in response to automated or interactive business processes.

Keeping aside the case of System for cross domain Identity Management (SCIM), traditional identity provisioning in cloud-based environments is similar to the diagram illustrated below (Figure 1) with multiple redundant integration efforts from the Enterprise Cloud Subscriber (ECS) to Cloud Service Providers (CSP).

Figure 1

In spite of the fact that this process works, maintenance of multiple connectors with added complexity and cost can be a nightmare. The simple solution for mitigating such scenarios is a simple open protocol that everyone agrees on which emphasizes the need for a system for cross-domain identity management for the identity provisioning. This is illustrated in Figure 2.

Figure 2

According to Request for Comments (RFC) 7642, the Internet Engineering Task Force (IETF) explains the need for SCIM as: The SCIM specification is designed to manage user identity in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability.

Managing Identities and User Provisioning with SCIM

SCIM is mainly used for managing identities and user accounts (user management) in cloud-based identity management systems. SCIM applies a standardized protocol across multiple user data sources. SCIM supports a fast, cheap, and an easy way to handle user operations on user identities between different identity domains.

The objects such as user object (user provisioning) and group object can be exchanged via SCIM. Managing identity data and automating the exchange of user identity data across apps and different identity domains for user provisioning are some of the main purposes of SCIM.

Identity provisioning consists of a set of actions between a service provider and the SCIM client. Using REST architecture and JSON representation, the SCIM protocol can communicate data about users and groups. The SCIM client knows how to perform SCIM operations such as HTTP POST to users and groups endpoint (/Users, /Groups) to create a new entry. Instead of using a different API for the same operation, applications that conform to the SCIM standard can instantly take advantage of pre-existing clients and code immediately.

The SCIM Versions

The first version, SCIM 1.0, was released in 2011 followed by the next release named version SCIM 1.1 in July 2012. The current standard, SCIM 2.0 was released as an IETF RFC in September 2015. Even though SCIM was initially designed with cloud-based use cases in mind, it turns out that a common language to move identities on-premises could also be an eminently useful scenario, which later created the platform for SCIM to be a major adoption.

The SCIM Specification

The SCIM specification has two major components:

• The SCIM core schema provides an abstract schema and extension model for representing users and groups. Standard serializations of that schema using JSON are provided.
• The SCIM protocol specification defines a REST API for exchanging identity resources via JSON.

SCIM Mechanism

SCIM is powered by the concepts of common user and group schemes and an extension model. It doesn’t just facilitate such schemes but is also a binding contract to exchange those schemes using a standard protocol, which makes SCIM an open connector.

The following diagram (Figure 3) illustrates the object model of SCIM 2.0. According to the SCIM standard, Resource is the common denominator and all SCIM objects are derived from it. A Resource has Id, externalId, and meta attributes and RFC7643 SCIM standard defines User, Group, and EnterpriseUser that extends the common attributes.

Figure 3

For resource manipulation purposes, SCIM provides a rich, but simple REST API with a set of operations powerful enough to perform massive bulk updates. Figure 4 shows a high-level overview of the HTTP methods and the SCIM usage for each.

Figure 4

SCIM defines endpoints according to the domain of the resource types to perform operations indicated above. /Users, /Groups, /Me, and /Bulk are such defined endpoints for resource manipulation purposes. To simplify interoperability, SCIM provides three endpoints as shown in Figure 5, /Serviceproviderconfig, /Resourcetype, and /Schema to discover supported features and specific attribute details.

Figure 5

For a better idea on how the SCIM protocol works, the following image (Figure 6) illustrates a simple user create request with user data through HTTP POST method to SCIM /Users endpoint. This user object contains a name attribute which is used as one of the complex attributes.

Figure 6

In response to the request, the server states the successful user creation with an HTTP status code 201 and returns the response of the created resource with the created user data as a JSON object in the response (Figure 7).

Figure 7

SCIM Use Cases

Understanding the use of SCIM in the real world could be challenging for a beginner. In this section, we will illustrate a high-level overview of five major use cases of SCIM. In each case, SCIM is used as an open connector which acts as a mutual agreement between two functionally separated parties.

For a better understanding, each SCIM use case is associated with a real-world scenario followed by a brief explanation about it.

1. Migration of Identities with SCIM

A company, ABC Enterprise, has an application called LetsChat, which uses identity information of its employees (e.g. user identity information/identifiers, attributes). This user identity information is stored in the cloud which is controlled by a free cloud service provider, FreeCloud. However ABC Enterprise has decided to move that identity information to a different cloud service provider, called SmartCloud, for better security and services. Apart from that, ABC Enterprise has purchased another application SecureMail, which also relies on identity information.
With the use of SCIM for all related parties, ABC Enterprise can easily migrate the identity information to SmartCloud without changing the representation of identity information and SecureMail can use the identity information straightaway without the need of an explicit connector. SO with SCIM this indeed saves time and cost and most importantly eliminates the pain associated with change. See Figure 8 for a visual summary.

Figure 8

2. Single Sign-On (SSO) Service with SCIM

Michelle has an account in her favorite social media application, PeopleBook which is hosted in a cloud service provider, SmartCloud. SmartCloud has federated their user identities with another cloud service provider, OurCloud. Michelle came up with a requirement to use an application called ManageMe which is hosted in OurCloud. ManageMe relies on the identity information provided by SmartCloud to authenticate Michelle. Hence, as seen in Figure 9, Michelle receives the requested service from ManageMe running on OurCloud without having to authenticate to that application explicitly.

Figure 9

SCIM schema and protocol provides the feasibility of establishing an open standard for exchanging the user identities between SmartCloud and OurCloud and also between applications and related cloud services. In short, SCIM creates a platform with inter-operable and scalable architecture and reduces the time and costs of all parties involved.

3. Provisioning of User Accounts (User Provisioning) for a Community of Interest (COI) with SCIM

HumanHR is an organization which provides human resource (HR) services to a community of interest — Orange Inc. Orange Inc has offices all around the world and their information systems are composed of a set of applications running on private and public clouds along with traditional IT systems. All local Orange Inc offices are responsible for collecting personal information of their employees (i.e. user identities and user attributes). On the other hand, HumanHR provides the HR services as Software as a Service (SaaS) on public and private clouds. Hence HumanHR is handling the identity information provisioning and distribution across all Orange Inc offices. Also, HumanHR allows management of personal information(user attributes) of the individual employees by themselves if they are eligible to do so. (e.g. users can update an address or telephone number by themselves).

Figure 10

As shown in Figure 10, this scenario simply emphasizes the need for an open connector for identity provisioning and distribution. Imagine the cost and time it would take if each Orange Inc local office used their own schema and protocol for identity exchange.

With a SCIM-based mechanism in place, all personal accounts are globally available to any authorized user or application across the Orange Inc system through the services provided by HumanHR within a blink of an eye.

4. Transfer of Attributes to a Relying Party’s Website with SCIM

Sam has an account in a directory service DServe. Sam then visits a website of a relying party Loople. The website requires some user attributes of the visited user to operate properly. On Sam’s first visit to the site, he selects the required attributes and authorizes the transfer of the attribute data from the directory service DServe to the Loople website through any authorization protocol (e.g. OAuth, SAML).

Figure 11

Again the SCIM schema and protocol is handy as it is required to build a mutual agreement between DServer and Loople to exchange attributes. As shown in Figure 11, usage of SCIM in a scenario like this would simply provide the service providers with secure, interoperable feasibility.

5. Change Notifications with SCIM

Sushiko has an account in the directory service WEServe and she has authorized the attribute transfer from WEServe to a relying party website example.com. The attributes of Sushiko change later in the directory service WEServe (e.g. Sushiko changes her name or mobile number). However example.com may have a cache of those attributes, and if it was aware of these changes to its cached copy, it would potentially cause a state change in it. However, the size of the changes could be substantially large and not all the changes will cause an interest in the relying party. Hence, directory service WEServe wishes to notify example.com that there are changes of potential interest such that example.com can at an appropriate time subsequently contact directory service WEServe and retrieve just the subset of changes of interest. This is highlighted by Figure 12.

Figure 12

Even with the change notification system, SCIM does not have to do much. This can be easily achieved by the interoperable and scalable nature of SCIM.

WSO2 Identity Server and SCIM

WSO2 Identity Server efficiently undertakes the complex task of identity management across enterprise applications, services, and APIs. It draws on the strengths of the most widely used standards and offers a platform-agnostic approach that allows enterprise architects to implement a uniform security layer upon existing assets across their digital business to facilitate easy identity management.

WSO2 Identity Server supports SCIM 1.1 and SCIM 2.0 for identity provisioning. In addition, WSO2 provides an open-source SCIM implementation named WSO2 Charon under Apache 2.0 license.

WSO2 Charon can be used by anyone who wants to add SCIM-based provisioning support for their applications. WSO2 Charon is integrated with WSO2 Identity Server to provide SCIM-based identity provisioning.

High Level Overview of SCIM Architecture

Figure 13 shows a high-level overview of the SCIM Service Provider architecture of WSO2 Identity Server.

Figure 13

Conclusion

SCIM protocol is designed to manage user identities in cloud-based applications and services in a standardized way. SCIM enables interoperability, security, and scalability. The SCIM specification suite seeks to build upon experiences with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. The intent of the SCIM specification is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard SCIM protocols. In essence, SCIM makes it fast, cheap, and easy to move users into, out of, and around the cloud.

References

• [1] SCIM Definitions, Overview, Concepts, and Requirements - https://tools.ietf.org/html/rfc7642
• [2] SCIM Protocol - https://tools.ietf.org/html/rfc7644
• [3] SCIM Core Schema - https://tools.ietf.org/html/rfc7643
• [4] https://medium.com/@vindulajayawardana/scim-make-it-fast-cheap-and-easy-b2bd56492c15
• [5] https://medium.com/@vindulajayawardana/5-things-that-will-not-be-a-nightmare-anymore-if-you-support-scim-9353d73836a7
• [6] https://wso2.com/identity-and-access-management