Hub documentation

Migration vers le SSO géré

Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Migration vers le SSO géré

Cette fonctionnalité fait partie de l'offre Enterprise Plus.

Ce guide s’adresse aux administrateurs d’organisation qui convertissent une organisation existante, d’une organisation standard en organisation Managed SSO.

La chose la plus importante à comprendre avant de commencer : les comptes Hugging Face personnels existants des membres ne sont pas convertis en comptes gérés. Chaque membre reçoit un tout nouveau compte géré, provisionné par votre Identity Provider (IdP). Avant qu’un membre puisse être provisionné, il doit libérer son adresse e-mail professionnelle sur son compte personnel.

Tout au long de ce guide, nous utilisons my-org comme nom d'organisation d'exemple.

Prérequis

SSO doit déjà être configuré, testé et activé sur votre organisation. La migration réutilise votre application OIDC ou SAML existante.

Étapes de migration

  1. Préparez vos membres. Parcourez la liste de contrôle avant migration avec vos membres.
  2. Contacter Hugging Face. Prenez contact avec l’équipe Hugging Face et confirmez le changement. Nous convertissons l’organisation et vous envoyons les identifiants du compte de secours my-org:owner.
  3. Demandez aux membres de libérer leurs adresses e-mail professionnelles. Consultez Libération des adresses e-mail professionnelles. Effectuez cette étape avant d’activer le provisioning : les utilisateurs déjà assignés à votre application SSO sont provisionnés dès l’activation de SCIM. L’équipe Hugging Face peut vous envoyer la liste des membres dont les comptes personnels utilisent encore une adresse e-mail professionnelle, afin que vous puissiez les contacter.
  4. Set up SCIM in your IdP. Utilisez l'URL du locataire SCIM et le jeton de votre organisation dans les paramètres SSO → SCIM de votre application OIDC ou SAML existante, puis suivez le guide correspondant à votre IdP.
  5. Affectez des utilisateurs et des groupes dans votre IdP. Les comptes gérés sont créés au fur et à mesure que les utilisateurs sont provisionnés.
  6. Supprimez les comptes personnels restants de l’organisation dès que le compte géré de chaque membre est provisionné. Cette étape est requise pour des raisons de sécurité, car les comptes personnels conservent un accès jusqu’à leur suppression. Leur suppression les retire également des groupes de ressources de l’organisation.
  7. (Facultatif) Associer des groupes à des groupes de ressources et des rôles. Associez vos groupes SCIM à des groupes de ressources et configurez le mappage des rôles pour attribuer des rôles d’organisation depuis votre IdP. Un groupe de ressources ne peut être associé à un groupe SCIM que s’il ne contient aucun membre et que l’adhésion automatique est désactivée. Si l’adhésion automatique est activée, les comptes gérés nouvellement provisionnés sont également ajoutés au groupe ; désactivez-la donc avant le provisionnement des utilisateurs, ou supprimez les membres restants avant l’association.

Quelles sont les modifications

Ce que fait la conversion

  • La conversion est effectuée par l’équipe Hugging Face. Il n’existe pas d’option d’auto-service. Une fois la demande effectuée, l’équipe Hugging Face bascule votre organisation en mode géré.
  • Le contenu et la configuration de votre organisation restent inchangés. Les dépôts, les paramètres, les Resource Groups et votre configuration SSO existante (application OIDC ou SAML) sont conservés. Vous conservez la même application IdP, bien que certains paramètres puissent nécessiter des ajustements pour SCIM (voir l’étape 4).
  • Un compte administrateur de secours est créé, nommé my-org:owner. Il se connecte avec un nom d'utilisateur et un mot de passe (pas via SSO) et est administrateur de l'organisation. L'équipe Hugging Face vous partage ses identifiants. Conservez-les en lieu sûr : ce compte vous permet d'accéder à votre organisation si votre IdP est indisponible ou mal configuré.
  • Le SSO ne peut plus être facultatif. Il peut toujours être désactivé complètement.

La désactivation du SSO sur une organisation gérée verrouille l’accès de tous les utilisateurs gérés, car les comptes gérés ne disposent d’aucun mot de passe.

Les comptes gérés sont de nouveaux comptes

  • Les comptes Hugging Face personnels existants ne sont pas convertis, fusionnés ni liés aux comptes gérés. Chaque membre reçoit un nouveau compte, créé par votre IdP via SCIM lorsque l’utilisateur est assigné dans l’IdP.
  • Les noms d'utilisateur gérés sont préfixés par le nom de l'organisation : <org-name>:<username>, par exemple my-org:jdoe.
  • Les utilisateurs gérés se connectent uniquement via votre IdP. Ils ne disposent d'aucun mot de passe Hugging Face, et l'option « Mot de passe oublié » ne fonctionne pas pour eux.
  • Les comptes gérés sont soumis aux restrictions applicables aux comptes gérés.

Adhésion

  • Les membres réguliers ne peuvent plus être ajoutés par invitation. Les membres internes doivent être provisionnés via SCIM.
  • Les invitations ne sont disponibles que pour les collaborateurs externes.

Comptes personnels existants dans l'organisation

Les comptes personnels qui restent membres de l’organisation après la conversion conservent leur rôle. Leurs jetons d’accès, les applications OAuth qu’ils ont déjà autorisées et le git via SSH continuent de fonctionner, car ces éléments ne sont pas vérifiés par rapport au SSO. Ils ne peuvent plus initier une nouvelle connexion SSO à l’organisation :

  • Si l'utilisateur est connecté avec son compte personnel, ou si ce compte a déjà été lié à votre IdP, il voit : You cannot login with SSO with this account because it's not managed by this organization. Contact your organization administrators.
  • Sinon, ils voient User not found.

Avant de migrer

Parcourez cette liste de contrôle avec vos membres avant de demander la conversion :

  • Dépôts personnels : les membres qui ont des dépôts dans leur espace de noms personnel et qui souhaitent continuer à y accéder avec leur nouveau compte géré doivent les transférer vers l’organisation avant le passage. Les comptes gérés ne peuvent pas posséder de contenu dans un espace de noms personnel. Les membres pourront toujours accéder aux dépôts de leur espace de noms personnel via leur compte personnel (non géré).
  • Jetons et automatisation : les jetons issus de comptes personnels conservent leur accès à l’organisation jusqu’à ce que le compte en soit retiré. Migratez les scripts, les tâches CI et les pipelines vers des comptes de service, ou vers des jetons créés à partir des comptes gérés après le basculement, puis supprimez les anciens comptes.
  • Autres organisations : les comptes gérés ne peuvent pas rejoindre d’autres organisations. Les membres qui doivent continuer à travailler dans d’autres organisations doivent conserver un compte personnel distinct (voir l’option 2 ci-dessous).
  • Adresses e-mail professionnelles : chaque membre doit libérer son adresse e-mail professionnelle avant d’être provisionné. Voir Libération des adresses e-mail professionnelles.

Libérer les adresses e-mail professionnelles

Une adresse e-mail ne peut appartenir qu’à un seul compte Hugging Face. Cela s’applique à toutes les adresses e-mail d’un compte, qu’elles soient principales ou secondaires. La correspondance est insensible à la casse.

Lorsque SCIM tente de créer un compte géré avec un e-mail professionnel déjà utilisé par un compte personnel, le provisionnement échoue avec une erreur 409 :

The email address (jdoe@example.com) is already associated with another Hugging Face account. Please delete the account.

Votre IdP affiche ceci comme une erreur d’approvisionnement pour cet utilisateur.

Pour éviter cela, chaque membre doit libérer son adresse e-mail professionnelle avant sa mise en place, en utilisant l'une des deux options ci-dessous.

Quelle option dois-je choisir ?

  • Si vous utilisez votre compte Hugging Face uniquement pour le travail au sein de cette organisation, choisissez l’option 1 : supprimez le compte personnel.
  • Si vous l’utilisez également pour du travail open source, des projets personnels ou d’autres organisations, choisissez l’option 2 : conservez le compte personnel et retirez l’adresse e-mail professionnelle.

Option 1 : Supprimer le compte personnel

Supprimez votre compte personnel depuis vos paramètres de compte. Cette action supprime définitivement tous les dépôts de votre espace de noms personnel et vous retire de toutes les organisations.

La suppression d'un compte est définitive. Transférez d'abord les dépôts que vous souhaitez conserver vers l'organisation.

La suppression est bloquée si vous êtes le seul administrateur d’une autre organisation. Ajoutez d’abord un autre administrateur à cette organisation, ou supprimez-la. L’organisation en cours de migration ne pose pas de problème, car my-org:owner est également administrateur.

Option 2 : Conserver le compte personnel

  1. Dans vos paramètres de compte, ajoutez une adresse e-mail personnelle et vérifiez-la.
  2. Rendez l’adresse e-mail personnelle votre adresse e-mail principale.
  3. Supprimez complètement l'adresse e-mail professionnelle. La définir comme adresse secondaire ne suffit pas.

Gardez votre compte personnel dans l’organisation jusqu’à ce que votre compte géré soit provisionné. Votre administrateur le retirera ensuite.

Si votre organisation a déjà activé le SSO géré et dispose d’un domaine de messagerie vérifié, la connexion avec une adresse e-mail sur ce domaine vous redirige vers la page SSO de l’organisation. Pour vous connecter à votre compte personnel, utilisez plutôt votre nom d’utilisateur.

Une fois l’adresse e-mail professionnelle libérée, l’administrateur peut réessayer le provisionnement pour cet utilisateur dans l’IdP, ou attendre que la prochaine synchronisation la prenne en compte.

Après la migration

Le cycle de vie des utilisateurs est géré depuis votre IdP :

  • Désactiver un utilisateur dans votre IdP le retire de l’organisation. Si le même utilisateur est réactivé plus tard, son compte géré existant est réutilisé.
  • Supprimer un utilisateur via SCIM supprime définitivement son compte géré. Consultez Déprovisionnement.
Update on GitHub