Provisionner des utilisateurs avec SCIM

Utilisez ce guide lorsque vous voulez maîtriser le cycle de vie : un départ doit révoquer les accès automatiquement, et pas seulement bloquer les connexions futures. SCIM est le protocole push que les IdP (Okta, Entra ID et autres) utilisent exactement pour cela.

Prérequis

• le SSO déjà opérationnel (le tutoriel SSO ou le guide OIDC),
• un serveur que l’IdP peut joindre en HTTPS — les appels SCIM viennent de l’IdP, et non du navigateur de l’utilisateur. Utilisez le tunnel intégré (Paramètres → Serveur → Connexion et état → Partager ce serveur → Cloudflared/ngrok/Tailscale) ou une URL publique. Un serveur joignable uniquement via le relais WebSocket ne peut pas recevoir de push SCIM ; le provisionnement JIT y fonctionne toujours, ce guide non.

Étapes

1. Ouvrez Paramètres → Serveur → Authentification unique → la carte Provisionnement des utilisateurs (SCIM). La carte affiche l’endpoint, par ex. https://<your-server>/scim/v2/Users.
2. Appuyez sur Générer un jeton (ou Régénérer le jeton s’il en existe déjà un) — le jeton bearer apparaît une seule fois dans une boîte de dialogue et est copié dans le presse-papiers. Conservez-le dans votre gestionnaire de mots de passe ; le serveur ne garde qu’une copie vérifiable à temps constant.
3. Dans les paramètres de provisionnement de votre IdP, activez SCIM avec :
   • URL de base : l’endpoint ci-dessus
   • Authentification : Authorization: Bearer <token>
   • Identifiant utilisateur : userName (e-mail) ou externalId — les deux correspondent
4. Testez avec un seul utilisateur : poussez-le depuis l’IdP, confirmez qu’il apparaît (la création SCIM fixe l’externalId du fournisseur sur le compte, le même rattachement qu’établit une première connexion SSO).

Ce que fait le déprovisionnement

Quand l’IdP envoie active: false (ou DELETE), SCIM refuse d’abord si le compte est propriétaire d’un espace de travail (transférez d’abord la propriété). Sinon :

1. chaque identifiant d’appareil est révoqué en premier — les sessions actives tombent en quelques secondes,
2. chaque appartenance à un espace de travail est supprimée,
3. le compte est marqué comme désactivé (il ne peut plus jamais se connecter, quoi que dise l’IdP par la suite, jusqu’à une réactivation explicite).

La ligne utilisateur elle-même subsiste — l’attribution sur les tickets, les messages et les commits est définitive. La réactivation (SCIM active: true) rétablit la connexion mais pas les appartenances : celles-ci nécessitent une nouvelle invitation ou la politique d’ajout automatique à la connexion.

Dépannage

• 401 à chaque appel — le jeton a changé ; régénérez-le et mettez à jour l’IdP.
• L’endpoint n’est pas joignable — le tunnel est hors service, ou le serveur fonctionne uniquement via le relais. SCIM exige du HTTPS direct ; le JIT continue de fonctionner dans tous les cas.
• Erreurs de push de groupes (501) — c’est intentionnel : le mappage groupe→rôle se fait à la connexion à partir des attributs de groupe SAML/OIDC, et non depuis les groupes poussés.