Identité et provisionnement (SCIM)

Scrydon prend en charge SCIM 2.0 (System for Cross-domain Identity Management) pour que votre fournisseur d'identité puisse automatiquement créer, mettre à jour et désactiver des utilisateurs dans Scrydon — et maintenir la synchronisation des appartenances aux groupes — sans aucune intervention manuelle de l'administrateur côté Scrydon.

Ce que fait SCIM

Groupes imbriqués

Les groupes SCIM dans Scrydon peuvent contenir d'autres groupes en tant que membres, pas uniquement des utilisateurs. Scrydon aplatit l'appartenance effective lors de la synchronisation vers une équipe Scrydon :

• Une équipe affiche toujours la liste effective des utilisateurs — les utilisateurs directs plus les utilisateurs transitifs de tout sous-groupe imbriqué.
• L'imbrication est prise en charge jusqu'à 3 niveaux de profondeur (parent → enfant → petit-enfant).
• Les cycles (le groupe A contient le groupe B, qui contient le groupe A) sont rejetés.
• Lorsque vous mettez à jour l'appartenance d'un groupe imbriqué, tous les groupes parents qui le contiennent sont resynchronisés à la prochaine opération.

Ce que SCIM ne fait pas

• Ne modifie pas les noms d'utilisateur ni les e-mails. Si l'e-mail d'une identité doit changer, déprovisionner et reprovisionner l'utilisateur à la place. (Même politique que Databricks, Snowflake et la plupart des cibles enterprise.)
• Ne renomme pas les équipes existantes. Si vous renommez un groupe dans votre IdP, l' Équipe Scrydon liée conserve son nom d'origine. Renommez l'équipe directement dans Scrydon si vous souhaitez la modifier.
• Ne synchronise pas les principaux de service / comptes machine. Uniquement les identités humaines. Créez les comptes de service directement dans Scrydon.
• Ne supprime pas les enregistrements utilisateur lors du déprovisionnement. Les utilisateurs sont désactivés (bannis + sessions révoquées + appartenance à l'organisation supprimée) mais la ligne utilisateur sous-jacente est préservée afin que l'historique d'audit, les ressources possédées et les traces de conformité restent intacts. Si le même utilisateur est reprovisionné ultérieurement (une réembauche, par exemple), Scrydon réactive automatiquement l'enregistrement existant plutôt que de créer un doublon.

Prérequis

1. Rôle d'administrateur d'organisation — seuls les administrateurs d'organisation peuvent générer ou révoquer des tokens SCIM.
2. SSO déjà configuré — SCIM et SSO sont complémentaires, pas des substituts. Les utilisateurs provisionnés via SCIM se connectent toujours via votre flux SSO.
3. L'un des IdP pris en charge — cette version couvre Microsoft Entra ID (Azure AD), Okta et OneLogin. Tout IdP SCIM 2.0 conforme à la RFC 7644 devrait fonctionner, mais ce sont les trois que nous testons.

Choisissez votre fournisseur d'identité

Limites de capacité

Scrydon applique des plafonds par organisation pour protéger l'infrastructure partagée d'un provisionnement excessif. Si votre organisation a besoin de limites plus élevées, contactez le support — ce sont des garde-fous, pas des plafonds architecturaux.

Fonctionnement du déprovisionnement

Lorsqu'un utilisateur est retiré de l'application Scrydon dans votre IdP (ou que l'IdP le marque comme inactif), Scrydon effectue une suppression douce :

1. Le compte utilisateur est banni — il ne peut plus se connecter par aucun moyen (SSO, lien magique, passkey).
2. Toutes les sessions actives sont révoquées immédiatement. Tout onglet Scrydon ouvert devient non authentifié à la prochaine action.
3. L'utilisateur est retiré de l'organisation, ce qui met fin à son accès à tous les espaces de travail, intégrations et données de cette organisation.
4. L'enregistrement utilisateur sous-jacent est conservé, de sorte que l'historique d'audit, les ressources possédées et les pistes de conformité restent intacts.

Si l'utilisateur est réajouté dans l'IdP ultérieurement, le reprovisionnement SCIM réactivera le même enregistrement — le même userId est utilisé, l'historique d'audit est continu.

Sécurité des tokens

Les tokens SCIM sont des credentials sensibles et doivent être traités comme des mots de passe ou des clés API. Le token brut vous est affiché une seule fois au moment de la génération — copiez-le immédiatement dans la configuration SCIM de votre IdP ou dans un gestionnaire de secrets. Si vous perdez un token, générez-en un nouveau et révoquez l'ancien.

Les tokens sont stockés dans la base de données Scrydon hachés (SHA-256) pour la vérification, aux côtés de la valeur brute qui est actuellement conservée pour que les tokens puissent être réaffichés dans l'interface d'administration après création. Le chiffrement au repos via le coffre de secrets Scrydon est prévu mais pas encore activé dans cette version — traitez l'accès aux tokens dans la base de données avec le même soin que tout magasin de credentials.

Nous recommandons de créer des tokens nommés distincts par environnement IdP — par exemple entra-prod et entra-staging — pour pouvoir effectuer des rotations ou des révocations indépendamment.

Journal d'audit

Chaque action SCIM est enregistrée dans le journal d'audit de Scrydon :

• Génération et révocation de tokens (avec l'administrateur d'organisation qui a effectué l'action)
• Provisionnement, liaison, mises à jour et déprovisionnement d'utilisateurs
• Création de groupes, ajouts de membres, suppressions de membres et suppression
• Tout appel SCIM rejeté (token invalide, conflit d'e-mail, plafond de capacité atteint)

Consultez le journal d'audit dans Paramètres → Platform → Journaux d'audit. Filtrez sur le préfixe d'événement scim.* pour ne voir que les entrées liées à SCIM. La liste complète des événements figure dans le catalogue des événements d'audit.

Associé

• Cloisonnement fort — restreignez les credentials système aux membres de l'espace de travail via un groupe de sécurité IdP.
• Opérations SCIM — runbooks pour les plafonds de capacité, la limitation, la dérive et la rotation.
• Catalogue des événements d'audit — chaque événement émis par la plateforme.