Vue d'ensemble SCIM — Token SCIM, provisionnement et authentification
SCIM 2.0 (System for Cross-domain Identity Management) automatise le provisionnement des utilisateurs et des groupes entre votre fournisseur d'identité et SecureCodingHub. Ajoutez, mettez à jour et supprimez des utilisateurs sans intervention manuelle — authentifié par un unique token SCIM émis depuis les paramètres de votre organisation.
Qu'est-ce que SCIM ?
SCIM synchronise automatiquement les événements de cycle de vie utilisateur depuis votre fournisseur d'identité vers SecureCodingHub : créer un utilisateur à l'embauche, mettre à jour les attributs lors d'un changement et désactiver lors de la désinscription. Cela élimine entièrement la gestion manuelle des utilisateurs.
Opérations prises en charge
Le point de terminaison SCIM 2.0 de SecureCodingHub prend en charge les ressources et opérations suivantes :
| Ressource | Opérations |
|---|---|
| Utilisateurs | Créer, Lire, Mettre à jour, Supprimer, Lister, Filtrer |
| Groupes | Créer, Lire, Mettre à jour, Supprimer, Lister |
| Service Provider Config | Lire (découverte) |
| Schémas | Lire (découverte) |
| Types de ressources | Lire (découverte) |
Authentification
L'API SCIM utilise l'authentification par token Bearer. Générez un token depuis le panneau d'administration SecureCodingHub et configurez-le dans votre fournisseur d'identité.
| Paramètre | Valeur |
|---|---|
| URL de base | https://api.limeplate.com/api/sch/scim/v2 |
| En-tête d'authentification | Authorization: Bearer {your-scim-token} |
Comment ça fonctionne
Configurer le provisionnement SCIM est un processus simple en quatre étapes :
L'administrateur génère un token SCIM dans SecureCodingHub
Le token est configuré dans le fournisseur d'identité (Okta, Azure AD)
L'IdP pousse les changements d'utilisateurs/groupes vers le point de terminaison SCIM SecureCodingHub
Les utilisateurs et les équipes sont créés, mis à jour et supprimés automatiquement
Pourquoi SCIM compte pour les preuves de conformité
SCIM n'est pas qu'une commodité opérationnelle. Pour les organisations opérant sous SOC 2, ISO 27001 ou HIPAA, la désinscription automatisée est le contrôle que les auditeurs testent réellement. L'Annexe A 9.2.6 d'ISO 27001 exige la suppression des droits d'accès à la fin de l'emploi, et SOC 2 Common Criteria 6.2 et 6.3 attendent que l'accès logique soit révoqué en temps voulu lorsqu'il n'est plus requis. Les processus de désinscription manuels échouent à ce test plus souvent qu'on ne le pense, car la piste de preuves repose sur le dépôt d'un ticket et qu'un humain se souvienne de cliquer à travers chaque outil en aval.
Lorsque SCIM est connecté à votre fournisseur d'identité, la désinscription devient un événement unique : les RH marquent l'utilisateur comme licencié dans le SIRH, l'IdP propage la désactivation et SecureCodingHub définit l'utilisateur inactif dans le cycle de provisionnement suivant. Les auditeurs obtiennent un journal propre des désactivations automatisées corrélées aux événements IdP, ce qui est exactement ce qu'ils veulent voir pendant une fenêtre d'observation Type II. Si vous vous préparez à un premier audit SOC 2, activer SCIM tôt et le laisser produire six mois de journaux propres est l'une des victoires de génération de preuves les moins coûteuses disponibles.
Schémas de déploiement courants
Trois schémas de déploiement couvrent la plupart des environnements. Les déploiements greenfield sont les plus simples : il n'y a pas d'utilisateurs existants dans SecureCodingHub, SCIM est activé avant que les premières invitations ne sortent et chaque utilisateur provient de l'IdP. C'est le modèle le plus propre et celui que nous recommandons chaque fois que c'est faisable. La synchronisation partielle est le schéma suivant : vous limitez SCIM à un seul groupe ou département, validez que les événements de cycle de vie se comportent correctement et étendez à partir de là. C'est utile pour les organisations avec des milliers de sièges où un mappage d'attribut mal configuré pourrait affecter de nombreux comptes à la fois.
Le troisième schéma consiste à fusionner SCIM avec des utilisateurs manuels existants. SecureCodingHub fait correspondre les utilisateurs SCIM entrants aux comptes existants sur l'adresse e-mail, donc la fusion est généralement non destructive. Le risque est que les utilisateurs créés manuellement avec une casse non correspondante, des adresses alias ou des valeurs d'e-mail obsolètes créent des doublons. Avant d'activer l'interrupteur, exportez votre liste d'utilisateurs actuelle, réconciliez-la avec la liste IdP et résolvez toute incohérence d'adresse dans l'IdP. Pour les détails sur la configuration des fournisseurs, voir les guides Configuration SCIM Okta et Configuration SCIM Azure AD.