System For Cross Domain Identity Management (SCIM)

  • By Vindula Jayawardana
  • 23 Oct, 2017

Introduction

Over the last decade, despite the negatives, the world is moving 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.

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 SCIM, traditional identity provisioning in cloud-based environments is similar to the diagram illustrated below with multiple redundant integration efforts from 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 emphasises the need for a system for cross-domain identity management for the identity provisioning.

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.

The SCIM Versions

The first version, SCIM 1.0, was released in 2011 followed by the next release named version 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 core schema provides an abstract schema and extension model for representing users and groups. Standard serializations of that schema using JSON is 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 illustrates the object model of SCIM 2.0. As shown below, Resource is the common denominator and all SCIM objects are derived from it. Resource has id, externalId and meta as attributes and RFC7643 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 operations powerful enough to perform massive bulk updates. Following is a high-level overview of the HTTP methods and the SCIM usage of them.

Figure 4

SCIM defines endpoints according to the domain of the resource type when performing the above operations. /Users, /Groups, /Me, and /Bulk are such defined endpoints for resource manipulation purposes. To simplify interoperability, SCIM provides three endpoints, /Serviceproviderconfig, /Resourcetype, and /Schema to discover supported features and specific attribute details.

Figure 5

For better understanding on how the SCIM protocol works, the following image illustrates a simple user creation operation through HTTP POST method to /Users endpoint.

Figure 6

In response to the request, the server states the successful user creation with an HTTP status code 201 and returns the representation of the created resource.

Figure 7

Use Cases

Understanding the use of SCIM in the real world could be somewhat 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 use case is associated with a real-world scenario followed by a brief explanation about it.

1. Migration of Identities

A company ABC Enterprise has an application LetsChat which uses identity information of its employees (e.g. identifiers, attributes). This 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 SmartCloud for better security and services. Apart from that, ABC Enterprise has purchased another application SecureMail which also relies on the 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. This indeed saves time as well as cost and most importantly eliminates the pain of change.

Figure 8

2. Single Sign-On (SSO) Service

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 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 the related cloud services. In short, it creates a platform with inter-operable and scalable architecture and reduces the time and costs of all the involved parties.

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

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 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 managing of personal information of the individual employees by themselves if they are eligible for doing that. (e.g. update of an address or a telephone number by the user himself).

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

Sam has an account in a directory service DServe. Sam then visits a website of a relying party Loople. The website requires some 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 come handy here as it is required to build a mutual agreement between DServer and Loople to exchange attributes. Usage of SCIM in a scenario like this would simply provide the service providers with secure, interoperable feasibility.

5. Change Notifications

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.

Figure 12

Even though with the change notification system, SCIM does not have to do much, the possibility of achieving the said mechanism is provided 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.

WSO2 Identity Server supports SCIM 1.1 and SCIM 2.0 for identity provisioning. In addition to that, 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 in order to provide SCIM-based identity provisioning.

The following is a high-level overview of the SCIM Service Provider architecture of WSO2 Identity Server.

Figure 13

Conclusion

The SCIM specification is designed to manage user identities in cloud-based applications and services in a standardized way to enable interoperability, security, and scalability. The specification suite seeks to build upon experience 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 protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.

References