SCIM : le provisioning automatique des identités

SCIM automatise le cycle de vie des comptes utilisateurs. Quand un collaborateur arrive, son compte est créé automatiquement dans toutes les applications. Quand il part, tous ses accès sont désactivés en quelques secondes, pas en quelques jours. Sans SCIM, vous gérez manuellement les comptes dans chaque application, avec les risques de sécurité et d'erreurs que cela implique.

Ce que vous allez apprendre

Ce guide vous explique SCIM, le standard pour synchroniser automatiquement les identités entre l'IdP et les applications. À la fin, vous saurez :

Comprendre pourquoi SCIM est nécessaire (et ses alternatives)
Maîtriser les opérations SCIM : création, modification, désactivation
Configurer un offboarding propre (désactiver + révoquer)
Anticiper les pièges courants d'implémentation

Prérequis : avoir lu Les bases de l'IAM.

Le problème : les comptes orphelins

Sans provisioning automatique, voici ce qui se passe :

Un employé arrive → création manuelle du compte dans chaque application
L'employé change de service → modification manuelle des groupes
L'employé part → on oublie de désactiver certains comptes

Résultat : des comptes orphelins qui persistent pendant des mois, voire des années. Le risque n'est pas théorique : ces comptes gardent leurs droits, n'apparaissent dans aucune revue puisque personne ne les réclame, et échappent souvent au MFA faute d'un utilisateur pour l'activer. Ils constituent une porte d'entrée idéale, sans propriétaire pour remarquer une connexion suspecte.

Les approches de provisioning

Just-in-Time (JIT) provisioning

Le compte est créé au premier login via SSO (OIDC/SAML).

Comment ça marche :

L'utilisateur se connecte pour la première fois
L'application reçoit l'assertion SAML ou l'ID Token
L'application crée le compte à partir des attributs reçus

Avantages :

Simple à mettre en place
Pas de synchronisation à maintenir

Limites :

Le compte n'existe qu'au premier login
Pas de pré-configuration (groupes, permissions spécifiques)
Pas de deprovisioning automatique

SCIM provisioning

L'IdP pousse les changements vers les applications en temps réel. La différence de fond avec le JIT tient à ce sens de circulation : ici, l'IdP n'attend pas que l'utilisateur se manifeste, il agit dès que la donnée change côté annuaire. C'est ce qui rend le deprovisioning possible, un départ n'étant jamais suivi d'une connexion qui aurait pu servir de déclencheur.

Comment ça marche :

Un utilisateur est créé/modifié/désactivé dans l'IdP
L'IdP envoie une requête SCIM à l'application
L'application applique le changement

Avantages :

Comptes pré-créés avant le premier login
Synchronisation des groupes et attributs
Deprovisioning automatique

Limites :

L'application doit supporter SCIM
Configuration plus complexe

SCIM : le protocole

SCIM (System for Cross-domain Identity Management) est défini par deux RFC :

RFC 7643 : Schéma SCIM (objets User, Group)
RFC 7644 : Protocole SCIM (API REST)

Cette séparation en deux documents a une conséquence concrète quand vous qualifiez une application : le support de SCIM n'est pas binaire. Un éditeur peut implémenter le schéma de la RFC 7643 tout en ne proposant qu'une partie des opérations de la RFC 7644, typiquement POST et PUT sans PATCH. Demandez toujours la liste des opérations supportées, pas seulement la mention « compatible SCIM 2.0 ».

Architecture SCIM

Le sens des flèches est le point important du schéma, et il surprend souvent : c'est l'IdP qui joue le rôle de client et l'application qui joue le rôle de serveur. Autrement dit, c'est l'annuaire central qui appelle l'API REST exposée par chaque application, et non l'inverse. Cette inversion explique deux contraintes pratiques : l'application doit publier un endpoint SCIM joignable depuis l'IdP, et chaque application détient son propre jeton d'authentification que l'IdP conserve.

Architecture SCIM : l'IdP (SCIM Client) pousse les utilisateurs vers l'application (SCIM Server) via l'API REST

L'IdP agit comme SCIM Client (pousse les changements). L'application agit comme SCIM Server (reçoit et applique).

Les objets SCIM

Le schéma RFC 7643 ne définit que deux ressources obligatoires, User et Group. Tout le reste (rôles applicatifs, licences, matricule) passe par des extensions de schéma, déclarées dans le tableau schemas. Lisez donc les exemples ci-dessous en regardant d'abord ce tableau : il indique quelle grammaire l'application doit savoir interpréter.

User

Dans la charge utile ci-dessous, trois champs pilotent tout le cycle de vie : externalId fait le lien avec l'IdP, active porte l'activation ou la désactivation du compte, et userName sert d'identifiant de connexion. Les autres attributs sont du confort d'affichage. Notez que id n'est pas fourni par l'IdP : c'est l'application qui le génère et le renvoie à la création.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "alice.martin",
  "userName": "alice.martin@example.com",
  "name": {
    "givenName": "Alice",
    "familyName": "Martin"
  },
  "emails": [
    {
      "value": "alice.martin@example.com",
      "type": "work",
      "primary": true
    }
  ],
  "active": true,
  "groups": [
    {
      "value": "developers",
      "display": "Developers Team"
    }
  ],
  "meta": {
    "resourceType": "User",
    "created": "2024-02-06T10:00:00Z",
    "lastModified": "2024-02-06T10:00:00Z"
  }
}

Attributs clés

Retenez surtout la paire id / externalId : c'est la source de la majorité des incidents de synchronisation. Chaque système garde son propre identifiant, et l'IdP doit mémoriser le id renvoyé par l'application pour pouvoir la mettre à jour ensuite. Si cette correspondance est perdue, l'IdP ne sait plus quel compte modifier et recrée des doublons au lieu de désactiver l'existant.

Attribut	Description
`id`	Identifiant unique côté application
`externalId`	Identifiant unique côté IdP
`userName`	Identifiant de login (souvent l'email)
`active`	Compte actif ou désactivé
`emails`	Liste des adresses email
`groups`	Groupes auxquels appartient l'utilisateur

Group

Un objet Group ne contient que son nom d'affichage et la liste de ses membres, référencés par leur id côté application. Conséquence directe : ajouter quelqu'un à un groupe se fait en modifiant le groupe, pas l'utilisateur. Beaucoup d'applications n'implémentent d'ailleurs que la ressource User et ignorent Group, auquel cas les appartenances doivent être gérées autrement, par exemple via un claim transmis au moment de la connexion SSO.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "id": "group-123",
  "displayName": "Developers Team",
  "members": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "display": "Alice Martin"
    }
  ]
}

Les opérations SCIM

CRUD sur les utilisateurs

Deux lignes de ce tableau méritent votre attention. PUT remplace l'objet entier : tout attribut absent de la charge utile est effacé côté application, ce qui écrase parfois des données que l'IdP ne connaît pas. PATCH ne touche que les chemins listés, c'est donc l'opération à privilégier pour un changement ciblé comme une désactivation. Quant à DELETE, il est marqué « rare » à dessein : la plupart des intégrations ne l'utilisent jamais.

Opération	Méthode HTTP	Endpoint	Usage
Créer	POST	`/Users`	Nouvel employé
Lire	GET	`/Users/{id}`	Vérifier un compte
Lister	GET	`/Users?filter=...`	Rechercher des utilisateurs
Modifier	PUT	`/Users/{id}`	Remplacement complet
Modifier partiellement	PATCH	`/Users/{id}`	Modification ciblée
Supprimer	DELETE	`/Users/{id}`	Suppression (rare)

Exemples de requêtes

Les trois échanges ci-dessous suffisent à couvrir 90 % d'une intégration réelle. Un détail les relie : le type de contenu application/scim+json, exigé par la RFC 7644. Beaucoup d'applications renvoient une erreur 415 Unsupported Media Type si vous envoyez un simple application/json, et c'est la première chose à vérifier quand un provisioning échoue sans message clair.

Créer un utilisateur :

POST /scim/v2/Users
Content-Type: application/scim+json
Authorization: Bearer <token>

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice.martin@example.com",
  "name": {
    "givenName": "Alice",
    "familyName": "Martin"
  },
  "emails": [{"value": "alice.martin@example.com", "primary": true}],
  "active": true
}

Désactiver un utilisateur (PATCH) :

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

Rechercher des utilisateurs :

GET /scim/v2/Users?filter=userName eq "alice.martin@example.com"

Le cycle de vie complet

Les trois moments qui suivent portent un nom dans le vocabulaire IAM : Joiner, Mover, Leaver. C'est le même flux de données à chaque fois, seule l'opération SCIM change. Le point de départ est toujours le système RH, jamais l'IdP : si un compte est créé directement dans l'annuaire, il sortira du cycle et deviendra un compte orphelin.

Onboarding (arrivée)

L'étape 4 est celle qu'on oublie de vérifier. Tant que l'IdP n'a pas mémorisé le id retourné par l'application, il ne pourra ni modifier ni désactiver ce compte plus tard. Un onboarding qui « fonctionne » mais dont la réponse n'a pas été enregistrée produit un compte que personne ne pourra fermer au départ du collaborateur.

Création dans l'IdP

Le RH crée l'utilisateur dans le système source (AD, Workday, HR system).
Synchronisation vers l'IdP

L'IdP central (Keycloak, Okta) reçoit l'utilisateur.
Provisioning SCIM

L'IdP pousse l'utilisateur vers les applications configurées.
Confirmation

Chaque application retourne un id SCIM que l'IdP stocke pour les futures mises à jour.

Changement de poste (Mover)

Le changement de poste est le scénario le plus mal traité en pratique, parce qu'il exige un retrait de droits, pas seulement un ajout. Un PATCH qui ajoute le nouveau groupe sans retirer l'ancien laisse la personne cumuler les accès de ses deux postes. Au bout de quelques mobilités internes, ce cumul donne des comptes plus privilégiés que ceux des administrateurs.

Modification des groupes dans l'IdP

L'utilisateur change d'équipe, ses groupes sont mis à jour.
PATCH SCIM vers les applications

L'IdP envoie les modifications de groupes.
Mise à jour des permissions

L'application ajuste les accès selon les nouveaux groupes.

Offboarding (départ)

Suivez bien l'ordre des quatre étapes : elles vont de la source vers les extrémités. La désactivation dans l'IdP ne coupe rien toute seule, elle ne fait que déclencher les PATCH vers les applications. C'est l'étape 3, la révocation des tokens, qui met réellement fin aux accès en cours, et c'est justement celle que beaucoup d'applications n'implémentent pas.

Désactivation dans l'IdP

Le compte est marqué active: false dans l'IdP.
PATCH SCIM : désactiver

L'IdP envoie { "active": false } à toutes les applications.
Révocation des tokens

Les applications invalident les sessions et tokens existants.
Blocage des logins

L'IdP refuse toute nouvelle authentification.

Offboarding propre

Un offboarding est dit propre quand aucune des cinq garanties ci-dessous ne manque. Le critère de validation est simple à énoncer et rarement testé : quelques minutes après la désactivation dans l'IdP, plus aucune requête authentifiée au nom de cette personne ne doit aboutir, ni depuis un navigateur déjà ouvert, ni depuis un jeton d'API encore valide.

Le compte est désactivé (plus de nouveaux logins)
Les sessions actives sont terminées
Les tokens (access, refresh) sont révoqués
Les accès API sont bloqués
Les données sont conservées ou archivées selon la politique

Implémentation

Le tableau se lit en colonnes : la partie gauche est ce que l'IdP déclenche, la partie droite ce que l'application doit effectivement faire pour que la promesse tienne. Le N/A de la ligne 2 n'est pas un détail : SCIM n'a aucune opération pour tuer une session. Si l'application ne coupe pas ses sessions d'elle-même à la réception de active: false, la personne reste connectée jusqu'à expiration naturelle du cookie.

Étape	Action IdP	Action Application
1. Désactivation	`active: false` dans l'IdP	SCIM PATCH reçu
2. Sessions	N/A	Invalider toutes les sessions du user
3. Tokens	Révoquer les refresh tokens	Supprimer les tokens stockés
4. Audit	Logger le deprovisioning	Logger la désactivation

Gestion des données

Le sort des données de la personne partie ne se décide pas au cas par cas au moment du départ : c'est une politique écrite à l'avance, sinon chaque offboarding devient une négociation. Les trois options ci-dessous s'excluent rarement, elles se combinent le plus souvent par type de donnée : conserver les traces d'audit, anonymiser les données personnelles au titre du RGPD, supprimer les brouillons personnels sans valeur.

Option	Quand l'utiliser
Conserver	Conformité, historique, audit
Anonymiser	RGPD, données personnelles
Supprimer	Demande explicite, données non critiques

Pièges courants

Ces cinq pièges se manifestent tous à la conception de l'intégration, pas à l'exploitation. Ils se traitent donc avant la mise en production, dans l'ordre du tableau : commencez par vérifier que l'application supporte réellement SCIM (beaucoup annoncent « SSO » sans provisioning), puis validez le mapping des identifiants, puis seulement testez les scénarios. Les erreurs de la section suivante, elles, apparaissent une fois le système en service.

Piège	Conséquence	Solution
L'app ne supporte pas SCIM	Provisioning manuel	Vérifier avant intégration
`externalId` vs `id` confondus	Échec des mises à jour	`externalId` = IdP, `id` = application
DELETE au lieu de désactiver	Perte d'historique	Toujours préférer `active: false`
Pas de révocation des sessions	Accès persistant après départ	Implémenter la révocation côté app
Mapping d'attributs incorrect	Données manquantes	Tester le mapping en pre-prod

Configuration Keycloak + SCIM

Keycloak ne supporte pas SCIM nativement, ni comme client ni comme serveur. C'est le principal écart fonctionnel avec les IdP commerciaux, et il se comble par une extension communautaire. Le choix n'est pas neutre : vous confiez le cycle de vie de vos comptes à un composant tiers dont le rythme de mise à jour ne suit pas forcément celui de Keycloak. Vérifiez sa compatibilité avec votre version avant chaque montée de version majeure.

Avec l'extension scim-for-keycloak

L'installation passe par le mécanisme de providers de Keycloak : un fichier JAR déposé dans /opt/keycloak/providers/, puis un kc.sh build qui reconstruit l'image de démarrage. Ce build est obligatoire, un simple redémarrage ne charge pas l'extension. Sur un Keycloak déployé en conteneur, la conséquence pratique est qu'il faut reconstruire l'image ou monter le JAR dans un volume persistant, sinon l'extension disparaît au prochain redéploiement.

Installer l'extension

# Ajouter le provider SCIM à Keycloak
cp scim-for-keycloak.jar /opt/keycloak/providers/
/opt/keycloak/bin/kc.sh build

Configurer le endpoint SCIM

Dans Keycloak Admin → Realm Settings → SCIM
Configurer l'application cliente

Entrer l'URL SCIM de l'application et le token d'authentification
Tester le provisioning

Créer un utilisateur dans Keycloak et vérifier sa création dans l'application

Okta / Azure AD

Ces IdP intègrent SCIM nativement, ce qui déplace la difficulté : le protocole n'est plus le sujet, le mapping des attributs le devient. C'est l'étape 4 qui prend le plus de temps, parce que chaque application attend ses champs sous un nom qui lui est propre. Passer par le catalogue d'applications plutôt que par une configuration SCIM générique vous évite ce travail : le connecteur embarque déjà le mapping validé par l'éditeur.

Ajouter l'application depuis le catalogue
Activer le provisioning
Entrer l'URL SCIM et le token de l'application
Mapper les attributs
Tester

SCIM vs autres approches

Le critère de choix n'est pas la qualité technique de chaque approche, c'est ce que l'application en face sait faire. Lisez la dernière colonne en premier : elle vous dit dans quel monde vous êtes. Une seule ligne devrait vous alerter, celle du JIT seul : sans deprovisioning, elle vous garantit des comptes orphelins à terme, et doit donc s'accompagner d'une revue d'accès périodique manuelle.

Approche	Avantages	Inconvénients	Usage
SCIM	Standard, temps réel, deprovisioning	L'app doit le supporter	SaaS modernes
JIT (SSO)	Simple, pas de config	Pas de deprovisioning	Apps sans SCIM
LDAP sync	Robuste, mature	Plus complexe, polling	Apps on-prem
API custom	Flexible	Sur-mesure, maintenance	Legacy, cas spéciaux

Erreurs fréquentes

Contrairement aux pièges de conception vus plus haut, ces quatre erreurs surviennent une fois l'intégration en service, et elles ont un point commun : elles ne produisent aucun message d'erreur visible. Un provisioning SCIM qui échoue le fait silencieusement, du côté de l'IdP, sur un compte qui n'existe pas encore et que personne ne cherche. D'où la ligne « Pas de monitoring » : sans alerte sur les échecs SCIM, vous découvrez le problème le jour d'un audit.

Erreur	Conséquence	Solution
Pas de test de deprovisioning	Comptes orphelins au premier départ	Tester le flow complet en pre-prod
Token SCIM en clair	Compromission possible	Stocker dans un vault
Pas de monitoring	Échecs silencieux	Alerter sur les erreurs SCIM
Mapping incomplet	Attributs manquants	Documenter et valider le mapping

À retenir

Références

Prochaines étapes

MFA et WebAuthn Renforcez l'authentification des comptes provisionnés.

RBAC et ABAC Modélisez les permissions des utilisateurs provisionnés.

Sécurité opérationnelle IAM Opérez un système d'identité en production.