What is a SCIM Schema?

SCIM (System for Cross-domain Identity Management) schemas are representations of a model. They are mainly used to represent users, groups... The RFC 7643, which we will see later, is a document describing these schemas in more detail. The format commonly used to represent these data schemas is JSON (JavaScript Object Notation). These schemas allow for a standardization of identity data which makes the use of SCIM possible. 

A few reminders about SCIM

The System for Cross-domain Identity Management is a protocol created in 2011. It was created following the influx of SSO (Single Sign-On) that was coming. Three RFCs  (Request For Comments) have also been created about it by the Internet Engineering Task Force (IETF): RFC 7642, 7643 and 7644. These three documents provide more details about the use of the SCIM protocol. The first one offers a use-case, the second one focuses specifically on the schemas and the third one on the protocol. SCIM allows you to manage cloud application identities. For example, if your company needs the services of company A and company B, the use of SSO coupled with SCIM would be a good idea. Indeed, the SSO will allow you to authenticate yourself on the application of company A and company B with a single login. The SCIM protocol will allow the communication of identities between the different actors. In other words, it represents resources (users, groups, ...) in a standardized way. 

The objectives of SCIM

The main objective of SCIM is to simplify the provisioning and deprovisioning of users. User provisioning or account provisioning is used to create, modify, deactivate and delete user accounts and their profiles in an IT infrastructure or any other application linked to this infrastructure. 

Moreover, it saves time and money for the companies that use it. Indeed, it reduces the cost and complexity of user management. The IT teams can therefore devote themselves to other tasks. Nevertheless, before implementing an SCIM, it is important to understand some notions.

A few notions before starting

After a quick review of SCIM and its advantages, we will study it in more detail. However, if you want to review the basics in more details, do not hesitate to consult our SCIM introduction article.

In this article we will focus on the SCIM Core Schema. As the name implies, a schema is nothing more than a simplified representation of an object. 

Nevertheless, before going any further, it is necessary to define two important notions: the SCIM service provider and the customer. 

The SCIM service provider is a Web application (HTTP). This web application will provide the identity information through the SCIM protocol. It will provide the identity information, when necessary, to the applications that need it.

The client is the application that made an HTTP SCIM request to the Service Provider in order to query the Service Provider or to manage the identity data it holds.

There are several types of requests called "methods". These methods will allow the client to perform different types of operations on the CRUD principle (Create, Read, Update, Delete).

The current version of SCIM is version 2.0 and is based on an object model. Resources are the core element of SCIM and all other elements are derived from these resources. Everything that can be managed by the SCIM service provider is a resource. Moreover, these resources are JSON objects, each of these objects can contain one or more attributes and these attributes can belong to one or more schemas.

Indeed, most of the time, a User resource contains attributes defined in the User and EnterpriseUser schemas 

To summarize, our resources will contain attributes that will be defined in one or more schemas. 

Resources and attributes

Resources are therefore important elements of the SCIM protocol. Each of these resources has attributes. Let's take the example of a user. Users are the "objects" that you will have to deal with most of the time. In SCIM, a user will be considered as a resource. This kind of resource has attributes that come up frequently, such as name, first name, e-mail address... This group of attributes will therefore define our User. 

Taking the example of a user, their schematic representation would be as follows:

In order to be used everywhere in the same way, the resources are all in JSON format. The representation of our "User" object in JSON would therefore look like this:

But what about the other attributes that could be specific to a particular application? This is where the EnterpriseUser comes in, it is a complement to our User that will contain other attributes that will be specific to applications. For example, if an application needs to know the native language of a user, then this attribute "native language" will belong to the EnterpriseUser schema.

But there are also other attributes common to resources such as Id, externalId and meta. These three attributes are attributes that can be found in the majority of SCIM resources. 

• The id represents a unique identifier for a SCIM resource as defined by the service provider. This attribute is mandatory and will always be present.
• The externalId represents a string that is an identifier for the resource as defined by the client. This attribute is optional.
• Meta which represents a complex attribute containing metadata of the resource. Like the creation date, the modification date... This attribute is a mandatory attribute.

The SCIM Schemas

Schemas represent a collection of attribute definitions, they allow us to describe the content of our resources. These schemas, like resources, are represented as JSON objects. 

Here is an example of schema, provided by the Internet Engineering Task Force :

In this schema we can see that attributes are defined by several parameters like 'required', 'mutablity'...

The definition of attributes

The definition of attributes will allow us to define our attributes, to know their characteristics. Thus, the attributes we define in our resources will have to match the definition we have given them. This is to ensure that our data conforms to our expectations and to avoid any errors.

According to RFC 7643, the SCIM protocol allows us to define the following parameters for the attributes:

• "name"
• "description"
• "type"
• "multiValued"
• "required"
• "canonicalValues"
• "caseExact"
• "mutability"
• "returned"
• "uniqueness"
• "subAttributes" (only in case the resource is a complex resource, i.e. an attribute is composed of several sub-attributes)
• “referencesTypes”

Let's go back to our previous example and focus only on the attribute definitions.

• Here the value contained in "name" represents the name of the attribute
• The "type" variable represents the type of data (here a string) which corresponds to a character string.
• The "multiValued" field which indicates if an attribute contains one or more values.
• The "description" field which provides a short description of the attribute
• The "required" field which specifies whether an attribute must be filled in or not.
• The "caseExact" field which specifies if a value is case sensitive or not (Example: If "Hello" = "hello" or not)
• The "mutability" field: unique keyword (readWrite, readOnly, immutable, writeOnly) indicating the circumstances in which the attribute value can be redefined.
• The "returned" field: a single keyword (always, never, default, request) that indicates when an attribute and associated values are returned in response to a GET request or in response to a PUT, POST or PATCH request.
• Finally the "uniqueness" field: unique keyword (none, server, global) which specifies how the service provider applies uniqueness to attribute values.

The last two possible parameters are "canonicalValue" and "referencesTypes", but are not present in our example.

The "canonicalValue" parameter can be used to specify values that could be used in our attribute. For example the "canonicalValue" of a "Nationality" attribute would be: "French", "German"...

The "referencesTypes" parameter represents a multi-valued array of JSON strings that indicate the types of SCIM resources that can be referenced (SCIM resource, external value, uri).

The different types of attributes

SCIM schemas, a set of rules to avoid errors.

As we have seen, SCIM schemas are very useful in the implementation of the SCIM protocol. Indeed, they allow us to define the resources thanks to "rules". These rules allow us to make sure that our resource is compliant and does not contain any errors. So schemas will be a great asset in the implementation of your SCIM!

So, ready to learn more about SCIM? We tell you more at Cryptr!