Qu'est-ce qu’un Schema SCIM ?

Les schémas SCIM (System for Cross-domain Identity Management ou en français Système de gestion des identités interdomaines) sont des représentations d’un modèle. Ils sont principalement utilisés pour représenter des utilisateurs, des groupes… La RFC 7643 que nous allons voir plus tard est un document décrivant plus en détail ces schémas. Le format communément utilisé pour représenter ces schémas de données est le JSON (JavaScript Object Notation). Ces schémas permettent d’avoir une uniformisation des données d’identités ce qui rend ainsi l’utilisation du SCIM possible. 

Quelques petits rappels concernant le SCIM

Le System for Cross-domain Identity Management est un protocole créé en 2011. Celui-ci a été créé suite à l’affluence des SSO (Single Sign-On) qui était en train d’arriver. Trois RFC (Request For Comments) ont par ailleurs été créés à son sujet par l’Internet Engineering Task Force (IETF) : les RFC 7642, 7643 et 7644. Ces trois documents fournissent plus de détails quant à l’utilisation du protocole SCIM. Le premier offre un cas d’usage (use-case), le second se concentre spécifiquement sur les schémas et le troisième sur le protocole plus précisément. Le SCIM permet de gérer les identités d’application cloud. Par exemple, si votre entreprise a besoin des services de l’entreprise A et de l’entreprise B, l’utilisation d’un SSO couplé au SCIM serait une bonne idée. En effet le SSO vous permettra de vous authentifier sur l’application de l’entreprise A et de l’entreprise B avec un seul et même identifiant. Le protocole SCIM va, quant à lui, permettre la communication des identités entre les différents acteurs. En d’autres termes, celui-ci permet de représenter de façon standardisée des ressources (des utilisateurs, des groupes, …). 

Les objectifs du SCIM

Le SCIM a pour objectif principal la simplification du provisioning et déprovisioning des utilisateurs. Le provisioning des utilisateurs ou provisioning des comptes sert à créer, modifier, désactiver et supprimer des comptes d'utilisateurs et leurs profils dans une infrastructure informatique ou toute autre application reliée à cette infrastructure. 

De plus, il permet un gain de temps et d’argent pour les entreprises qui l’utilisent. En effet, il réduit le coût et la complexité de la gestion des utilisateurs. Les équipes IT pourront donc se consacrer à d’autres tâches. Néanmoins avant de mettre un SCIM en place il faut comprendre certaines notions importantes.

Quelques notions avant de débuter

Après avoir revu de manière rapide le SCIM et ses avantages, nous allons pouvoir étudier celui-ci plus en détail. Néanmoins, si vous voulez revoir les bases de manière plus poussée n’hésitez pas à consulter notre article d’introduction au SCIM.

Dans cet article nous allons donc nous concentrer sur le Core Schema du SCIM. Comme son nom l’indique, un schéma n’est autre qu’une représentation simplifiée d’un objet. 

Néanmoins, avant de continuer plus loin, il est nécessaire de définir deux notions importantes : le fournisseur de service SCIM et le client. 

**Le fournisseur de service SCIM **est une application Web (HTTP). C’est cette application Web qui va fournir les informations d’identités par l'intermédiaire du protocole SCIM. Celle-ci va fournir les informations d'identité, quand cela est nécessaire, aux applications en ayant le besoin.

**Le client **est l’application ayant effectué une requête HTTP SCIM vers le fournisseur de service afin d’interroger celui-ci ou de gérer les données d’identités qu’il possède.

Il existe plusieurs types de requêtes appelées « méthodes ». Ces méthodes vont permettre au client d’effectuer différents types d’opérations sur le principe du CRUD (Create, Read, Update, Delete).

La version actuelle du SCIM est la version 2.0 et celle-ci est basée sur un modèle objet. Les ressources sont l’élément central du SCIM et tous les autres éléments découlent de ces ressources. Tout ce qui va pouvoir être géré par le fournisseur de service SCIM est donc une ressource. De plus, ces ressources sont des objets JSON, chacun de ces objets peut contenir un ou des attributs et ces attributs peuvent appartenir à un ou plusieurs schémas.

En effet la plupart du temps, une ressource User contient des attributs définis dans les schémas User et EnterpriseUser 

Pour résumer, nos ressources vont contenir des attributs qui eux seront définis dans un ou plusieurs schémas. 

Des ressources et des attributs

Les ressources sont donc des éléments importants du protocole SCIM. Chacune de ces ressources possède des attributs. Prenons l’exemple d’un utilisateur. Les utilisateurs sont les « objets » que vous allez devoir traiter le plus fréquemment. En SCIM un utilisateur sera considéré comme une ressource. Ce genre de ressource présente des attributs qui reviennent fréquemment comme le nom, le prénom, l’adresse mail… Ce groupe d’attributs va donc définir notre User. 

En prenant l’exemple d’un utilisateur, sa représentation schématique serait la suivante :

Pour pouvoir être utilisées partout de la même manière, les ressources sont toutes au format JSON. La représentation de notre objet « User » en JSON ressemblerait donc à ceci :

Mais qu’en est-il des autres attributs qui pourraient être spécifiques à une application en particulier ? C’est là qu’intervient l’EnterpriseUser, celui-ci est un complément à notre User qui contiendra d’autres attributs qui eux seront spécifiques aux applications. Par exemple, si une application a besoin de connaître la langue maternelle d’un utilisateur, alors cet attribut “langueMaternelle” appartiendra au schéma EnterpriseUser.

Mais il existe aussi d’autres attributs communs aux ressources comme l’Id, l’externalId et meta. Ces trois attributs sont des attributs que l’on retrouve dans la majorité des ressources en SCIM. 

• L’id représente un identifiant unique pour une ressource SCIM tel que défini par le fournisseur de services. Cet attribut est obligatoire et sera toujours présent.

• L’externalId représente une chaîne de caractère qui est un identifiant pour la ressource tel que défini par le client. Cet attribut est optionnel.

• Meta qui représente un attribut complexe contenant des métadonnées de la ressource. Comme la date de création, la date de modification… Cet attribut est un attribut obligatoire.

Les schémas

Les schémas représentent une collection de définitions d’attributs, ils permettent de décrire le contenu de nos ressources. Ces schémas, tout comme les ressources, sont représentés sous la forme d’objet JSON. 

Voici un exemple de schéma, fournis par l’Internet Engineering Task Force :

Dans ce schéma on peut voir que les attributs sont définis par plusieurs paramètres comme ‘required’, ‘mutablity’...

La définition d’attributs

La définition d’attributs va nous permettre de définir nos attributs, de connaître leurs caractéristiques. Ainsi les attributs que nous définirons dans nos ressources devront correspondre à la définition que nous leur avons fournie. Cela afin de s’assurer que nos données sont conformes à nos attentes et d’éviter toute erreur.

D’après la RFC 7643, le protocole SCIM nous permet de définir les paramètres ci-dessous pour les attributs :

• "name"

• "description"

• "type"

• "multiValued"

• "required"

• "canonicalValues"

• "caseExact"

• "mutability"

• "returned"

• "uniqueness"

• "subAttributes" (seulement dans le cas où la ressource est une ressource complexe, c’est à dire, qu’un attribut est composé de plusieurs sous-attributs)

• “referencesTypes”

Reprenons notre exemple précédent et concentrons-nous uniquement sur les définitions d’attributs.

• Ici la valeur contenue dans “name” représente le nom de l’attribut

• La variable “type” représente le type de données ici un string qui correspond à une chaîne de caractères.

• Le champ “multiValued” qui indique si un attribut contient une seule ou plusieurs valeur(s).

• Le champ “description” qui fournit une courte description de l’attribut

• Le champ “required” qui précise si un attribut doit obligatoirement être renseigné ou non.

• Le champ “caseExact” qui spécifie si une valeur est sensible à la casse ou non. (Exemple : Si “Hello” = “hello” ou non)

• Le champ “mutability” : mot-clé unique (readWrite, readOnly, immutable, writeOnly) indiquant les circonstances dans lesquelles la valeur de l'attribut peut être redéfinie.

• Le champ “returned” : mot clé unique (always, never, default, request) qui indique quand un attribut et les valeurs associées sont renvoyés en réponse à une requête GET ou en réponse à une requête PUT, POST ou PATCH.

• Enfin le champ “uniqueness” : mot -clé unique (none, server, global) qui spécifie comment le fournisseur de services applique l'unicité des valeurs d'attribut.

Les deux derniers paramètres possibles sont “canonicalValue” et “referencesTypes”, mais ne sont pas présents dans notre exemple.

Le paramètre “canonicalValue” peut être utilisé pour spécifier des valeurs qui pourraient être utilisées dans notre attribut. Par exemple les “canonicalValue” d’un attribut “Nationalité” seraient : "Française", “Allemande”...

Le paramètre “referencesTypes” quant à lui représente un tableau à plusieurs valeurs de chaînes JSON qui indiquent les types de ressources SCIM qui peuvent être référencés (ressource SCIM, valeur externe, uri)

Les différents types d’attributs

Les schemas SCIM, une suite de règles permettant d’éviter les erreurs.

Comme nous l’avons vu, les SCIM schemas sont très utiles dans la mise en place du protocole SCIM. En effet, ils permettent de définir les ressources grâce à des "règles”. Ces règles permettent de nous assurer que notre ressource est conforme et ne comporte pas d’erreurs. Les schémas seront donc un atout de taille dans la mise en place de votre SCIM !

Alors prêt à en apprendre plus sur le SCIM ? On vous en dit plus chez Cryptr !