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 :

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

Résultat : des comptes orphelins qui persistent pendant des mois, voire des années. Un risque de sécurité majeur.

Chiffre clé

Selon les audits IAM, une entreprise moyenne a entre 10% et 30% de comptes orphelins dans ses applications SaaS.

Les approches de provisioning

Just-in-Time (JIT) provisioning

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

Comment ça marche :

1. L’utilisateur se connecte pour la première fois
2. L’application reçoit l’assertion SAML ou l’ID Token
3. 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.

Comment ça marche :

1. Un utilisateur est créé/modifié/désactivé dans l’IdP
2. L’IdP envoie une requête SCIM à l’application
3. 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

JIT + SCIM = complémentaires

En pratique, on combine souvent les deux :

• SCIM pour le provisioning initial et le deprovisioning
• JIT pour les mises à jour d’attributs au login

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)

Architecture SCIM

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

Les objets SCIM

User

{
  "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

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

Glissez pour voir

Group

{
  "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

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)

Glissez pour voir

Exemples de requêtes

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

Onboarding (arrivée)

1. Création dans l’IdP

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

2. Synchronisation vers l’IdP

   L’IdP central (Keycloak, Okta) reçoit l’utilisateur.

3. Provisioning SCIM

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

4. Confirmation

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

Changement de poste (Mover)

1. Modification des groupes dans l’IdP

   L’utilisateur change d’équipe, ses groupes sont mis à jour.

2. PATCH SCIM vers les applications

   L’IdP envoie les modifications de groupes.

3. Mise à jour des permissions

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

Offboarding (départ)

1. Désactivation dans l’IdP

   Le compte est marqué active: false dans l’IdP.

2. PATCH SCIM : désactiver

   L’IdP envoie { "active": false } à toutes les applications.

3. Révocation des tokens

   Les applications invalident les sessions et tokens existants.

4. Blocage des logins

   L’IdP refuse toute nouvelle authentification.

Désactiver ≠ Supprimer les sessions

Désactiver le compte empêche les nouveaux logins. Mais les sessions existantes peuvent persister ! Assurez-vous que l’application révoque aussi les tokens/sessions actifs.

Offboarding propre

Un offboarding “propre” doit garantir que :

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

Implémentation

É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

Glissez pour voir

Gestion des données

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

Glissez pour voir

Pièges courants

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

Glissez pour voir

Configuration Keycloak + SCIM

Keycloak ne supporte pas SCIM nativement, mais plusieurs extensions existent.

Avec l’extension scim-for-keycloak

1. Installer l’extension

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

2. Configurer le endpoint SCIM

   Dans Keycloak Admin → Realm Settings → SCIM

3. Configurer l’application cliente

   Entrer l’URL SCIM de l’application et le token d’authentification

4. Tester le provisioning

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

Okta / Azure AD

Ces IdP supportent SCIM nativement :

1. Ajouter l’application depuis le catalogue
2. Activer le provisioning
3. Entrer l’URL SCIM et le token de l’application
4. Mapper les attributs
5. Tester

SCIM vs autres approches

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

Glissez pour voir

Erreurs fréquentes

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

Glissez pour voir

À retenir

Les 7 points clés

1. SCIM synchronise automatiquement les identités IdP → applications
2. L’IdP est SCIM Client, l’app est SCIM Server
3. Désactiver (active: false) plutôt que supprimer (préserve l’historique)
4. Un offboarding propre = désactiver + révoquer sessions + révoquer tokens
5. JIT crée au premier login, SCIM pré-crée et synchronise en continu
6. Tester le deprovisioning avant la mise en production
7. Surveiller les erreurs SCIM (échecs silencieux = comptes orphelins)

Références

• RFC 7643 — SCIM Core Schema
• RFC 7644 — SCIM Protocol
• SCIM 2.0 Overview (simplecloud.info)

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.

×

📖 Voir la documentation →