Skip to main content

Enterprise Server 3.20 est actuellement disponible en tant que version candidate.

Déprovisionnement et réintégration des utilisateurs avec SCIM

Consultez les informations détaillées concernant la suppression ou la réactivation des utilisateurs .

Qui peut utiliser cette fonctionnalité ?

Enterprises that use Enterprise Managed Users, or GitHub Enterprise Server instances with SCIM enabled

Si vous avez activé SCIM pour votre instance GitHub Enterprise Server, vous devrez utiliser SCIM pour :

  • Supprimez les privilèges des utilisateurs et des groupes pour leur retirer l’accès.
  • Réactivez les comptes des utilisateurs précédemment désactivés.

Avant de supprimer les privilèges d’accès d’un utilisateur, il est important de comprendre les effets de cette suppression, qui dépendent du type d’appel d’API de suppression que GitHub reçoit de votre fournisseur d’identité.

Important

Avant de poursuivre votre lecture, assurez-vous de bien comprendre comment votre entreprise a implémenté SCIM. GitHub met à disposition une application « paved-path » lorsque vous utilisez un IdP pris en charge pour l’authentification et le provisionnement. Si vous n’utilisez pas d’application « paved-path », vous devrez utiliser l’API REST pour effectuer des requêtes SCIM. Consultez À propos de l’approvisionnement d’utilisateurs avec SCIM sur GitHub Enterprise Server.

Types de déprovisionnement des utilisateurs

Lorsqu’un utilisateur voit ses privilèges d’accès supprimés, le compte GitHub est suspendu, ce qui signifie que l’utilisateur ne peut plus accéder à votre entreprise. Quel que soit le type de suppression des privilèges d’accès, un compte dont les accès ont été supprimés n’est jamais supprimé de l’entreprise.

Le type d’appel de suppression des privilèges d’accès que GitHub reçoit de votre fournisseur d’identité détermine s’il est possible de réactiver (rétablir) un utilisateur dont les privilèges ont été supprimés.

  •         **Suppression temporaire des privilèges d’accès** : dans certaines situations, l’utilisateur peut être réactivé via votre intégration SCIM.
    
  •         **Suppression définitive des privilèges d’accès** : la réactivation de l’utilisateur est impossible. Un nouveau compte doit être créé si la personne doit récupérer son accès.
    

Effets du retrait des droits d'accès d'un utilisateur

Lorsque vous déprovisionnez un compte utilisateur, que ce soit via votre fournisseur d'identité ou l'API REST, GitHub apportera des modifications au compte utilisateur.

Conséquences de la désactivation temporaire

  • L’utilisateur est suspendu et perd l’accès à votre entreprise et à toutes les ressources privées.
  • Une fois le compte d’utilisateur suspendu, il apparaîtra dans la liste « Membres suspendus » au lieu de la liste « Membres » dans la section « Personnes » des paramètres de l’entreprise.
  • Le nom d’utilisateur est obscurci par un hachage du nom d’utilisateur d’origine .
  • Avec Entra ID, l’adresse e-mail de l’utilisateur reste la même. Dans tous les autres cas, l’adresse e-mail de l’utilisateur est masquée.
  • L’identité SCIM de l’utilisateur reste liée à son compte d’utilisateur sur GitHub. Avec Entra ID, la valeur de l’attribut active dans leur identité SCIM liée stockée est mise à jour de True à False.
  • Si l’utilisateur dispose de duplications (forks) de référentiels privés ou internes, celles-ci sont supprimées dans les 24 heures. Les fourches sont restaurées si l’utilisateur est réactivé dans un délai de 90 jours.
  • Si l’utilisateur appartient à un groupe IdP provisionné par SCIM, il est masqué dans ces groupes et retiré de toutes les équipes associées à ces groupes par mappage. Notez que ce comportement se produit même si l’utilisateur demeure membre du groupe du côté IdP.
  • Si l’appartenance à une organisation est gérée par des groupes de fournisseurs d’identité, l’utilisateur sera retiré des organisations lorsqu’il sera retiré de ces groupes de fournisseurs d’identité ou retiré de toutes les équipes mappées aux groupes de fournisseurs d’identité dans l’organisation.
  • Si l’appartenance à l’organisation est gérée directement, l’utilisateur restera un « membre suspendu » de l’organisation, sans accès, jusqu’à ce qu’il soit retiré manuellement.

Conséquences de la suppression définitive

  • L’utilisateur est suspendu et perd l’accès à votre entreprise et à toutes les ressources privées.
  • Une fois le compte d’utilisateur suspendu, il apparaîtra dans la liste « Membres suspendus » au lieu de la liste « Membres » dans la section « Personnes » des paramètres de l’entreprise.
  • Le nom d’utilisateur est obscurci par un hachage du nom d’utilisateur d’origine .
  • L’adresse e-mail de l’utilisateur est masquée.
  • Le nom d’affichage de l’utilisateur devient une chaîne vide.
  • L’identité SCIM liée à l’utilisateur, y compris tous les attributs SCIM de l’utilisateur, est supprimée.
  • Les personal access tokens, fine-grained personal access tokens, clés SSH, clés GPG et autorisations d'application de l'utilisateur sont supprimés. La suppression de clés peut affecter la vérification des commits. Consultez « À propos de la vérification des signatures de commit ».
  • Les référentiels appartenant à l’utilisateur sont supprimés.
  • Les ressources créées par l’utilisateur, telles que les commentaires, sont conservées.
  • Si l’utilisateur appartient à un groupe IdP provisionné par SCIM, il est masqué dans ces groupes et retiré de toutes les équipes associées à ces groupes par mappage. Notez que ce comportement se produit même si l’utilisateur demeure membre du groupe du côté IdP.
  • Si l’appartenance à une organisation est gérée par des groupes de fournisseurs d’identité, l’utilisateur sera retiré des organisations lorsqu’il sera retiré de ces groupes de fournisseurs d’identité ou retiré de toutes les équipes mappées aux groupes de fournisseurs d’identité dans l’organisation.
  • Si l’appartenance à l’organisation est gérée directement, l’utilisateur restera un « membre suspendu » de l’organisation, sans accès, jusqu’à ce qu’il soit retiré manuellement.

Actions qui déclenchent le déprovisionnement

Différentes actions déclenchent une déprovisionnement souple ou rigide, et ces déclencheurs varient en fonction de l'intégration SCIM. De manière générale, la majorité des actions réalisées dans les applications IdP « paved-path » entraînent uniquement une suppression temporaire des privilèges d’accès, avec quelques exceptions.

Déclencheurs de la suppression temporaire

Intégration SCIMDéclencheur de la suppression temporaire
API RESTUne requête PUT ou PATCH est envoyée à /scim/v2/Users/{scim_user_id}, mettant à jour le champ active d’un utilisateur avec false.
Entra IDUn utilisateur est désactivé dans Entra ID, désaffecté de l’application, retiré de tous les groupes auxquels il était affecté ou supprimé temporairement du locataire par l’administrateur. Pour plus d’informations, consultez la section Suppression temporaire dans la documentation Microsoft.
OktaUn utilisateur est désaffecté de l’application, retiré de tous les groupes auxquels il est affecté ou désactivé à l’aide du bouton « Désactiver ». Veuillez noter que le bouton « Suspendre » n’envoie pas de requête à GitHub. Okta envoie uniquement des appels de désactivation temporaire.
PingFederateL’utilisateur est suspendu, désactivé ou retiré du magasin d’utilisateurs ciblé par l’approvisionneur.

Déclencheurs de la désactivation définitive

Intégration SCIMDéclencheur du déprovisionnement forcé
API RESTUne requête DELETE est envoyée à /scim/v2/Users/{scim_user_id}.
Entra IDLa suppression complète d’un compte d’utilisateur Entra ID, telle que décrite dans Suppressions complètes dans la documentation de Microsoft. Les utilisateurs Entra ID qui ont été supprimés temporairement (figurant sur la page « Utilisateurs > Utilisateurs supprimés » du portail d’administration Entra ID) sont automatiquement supprimés définitivement par Entra ID 30 jours après leur suppression temporaire.
OktaN/A. Okta n’envoie pas d’appels de déprovisionnement complet.
PingFederateSi le paramètre « Action de suppression de l'utilisateur » est défini sur « Supprimer » au lieu de « Désactiver » à cause d’une mauvaise configuration, cette action enverra un appel de déprovisionnement complet. Consultez la documentation PingIdentity.

Réactivation d’un compte utilisateur précédemment désactivé temporairement

Pour rétablir l’accès et les informations du compte utilisateur, vous pouvez reprovisionner le compte d’un utilisateur qui a fait l’objet d’une suppression temporaire des privilèges d’accès, à condition que le compte utilisateur IdP reste identique. Le compte utilisateur IdP doit être strictement le même, car un compte utilisateur qui a fait l’objet d’une suppression temporaire des privilèges d’accès demeure lié à cette identité externe, sur la base du SCIM external ID (ID d’objet utilisateur IdP) et du SCIM User ID. L’identité externe associée à un compte utilisateur individuel désapprovisionné de manière souple ne peut pas être modifiée.

Effets de la réattribution

  • L’utilisateur n’est plus suspendu et retrouve l’accès à votre entreprise.
  • Le nom d’utilisateur et l’adresse e-mail de l’utilisateur sont restaurés.
  • Si l’utilisateur est membre d’un groupe IdP approvisionné par SCIM, associé à une équipe au sein d'une organisation, il sera ajouté à l’organisation immédiatement après le réapprovisionnement de son compte d’utilisateur. S’il était déjà membre de l’organisation, son appartenance sera rétablie, à condition que son retrait n’ait pas eu lieu il y a plus de 90 jours. Consultez « Réactivation d’un ancien membre de votre organisation ».
  • Si l’utilisateur n’appartient pas à un groupe IdP attribué par SCIM faisant l’objet d’un mappage avec une équipe dans une organisation, un propriétaire de l’organisation GitHub devra ajouter manuellement son compte utilisateur à l’organisation après sa réattribution.
  • Les fourches supprimées sont restaurées si l’utilisateur est réactivé dans les 90 jours suivant sa suspension.
  • Les éléments associés à l’utilisateur sont restaurés, notamment :
    • GitHub Apps, OAuth apps et autorisations d’application
    • Personal access tokens
    • Clés SSH
    • Autorisations de jeton et de clé
    • Référentiels appartenant à l’utilisateur

Actions qui déclenchent le réapprovisionnement

La méthode de réapprovisionnement d’un utilisateur dépend de votre intégration SCIM et de l’action ayant déclenché le désapprovisionnement temporaire.

Implémentation SCIMAction pour réapprovisionner les utilisateurs
Entra IDRéactivez un compte désactivé ou réaffectez un utilisateur à l’application, soit directement, soit via un groupe affecté. Attendez 40 minutes pour que les modifications soient prises en compte, ou accélérez le processus en cliquant sur le bouton « Approvisionnement à la demande ».
OktaRéactivez le compte ou réaffectez l’utilisateur à l’application, soit directement, soit via un groupe.
PingFederateRéactivez l’utilisateur dans le magasin d’utilisateurs, ou ajoutez-le de nouveau au groupe ou au filtre du magasin de données ciblé par le provisionneur.
API RESTEnvoyez une requête PUT ou PATCH à /scim/v2/Users/{scim_user_id}, en mettant à jour le champ active de l’utilisateur avec true.

Rétablissement d’un compte d’utilisateur qui a été complètement déprovisionné

Vous ne pouvez pas restaurer un compte d’utilisateur GitHub qui a été irréversiblement désactivé via SCIM. Vous devrez plutôt approvisionner un nouveau compte GitHub pour l’utilisateur.

Le nom d’utilisateur d’un utilisateur désapprovisionné de manière définitive peut être réutilisé lors du provisionnement d’un nouveau compte. La fusion du compte utilisateur désapprovisionné de manière définitive avec un nouveau compte utilisateur sur GitHub n’est pas possible.

  • Si les adresses e-mail de l'utilisateur dont les privilèges d’accès ont été supprimés de manière irréversible et du nouvel utilisateur correspondent, GitHub attribue des validations Git existantes associées à l'adresse e-mail au nouvel utilisateur.
  • Les ressources existantes et les commentaires créés par l’utilisateur d’origine ne seront pas associés au nouvel utilisateur.

Événements du journal d'audit

Le journal d’audit de votre entreprise affiche des détails sur l’activité dans votre entreprise. Vous pouvez utiliser le journal d’audit pour prendre en charge votre configuration de SCIM. Pour plus d’informations, consultez « Journal d’audit pour une entreprise ».

Important

Nous recommandons vivement aux propriétaires d’entreprises d’activer les fonctionnalités de journalisation d’audit d’entreprise telles que la diffusion en continu des journaux d’audit, la divulgation de l’adresse IP source et l’option de diffusion en continu des requêtes API. La diffusion en continu de ces événements permet aux administrateurs de définir une stratégie de conservation des journaux adaptée aux besoins de leur entreprise et d’utiliser leurs outils préférés pour interroger ces journaux.

Événements liés au désapprovisionnement temporaire

Lorsque vous déprovisionnez de manière réversible un utilisateur, l'événement external_identity.update n'apparaît pas dans le journal d'audit. Les événements suivants s'affichent dans le journal d'audit :

  • user.suspend
  • user.remove_email
  • user.rename
  • external_identity.deprovision
  • Si la demande réussit, external_identity.scim_api_success
  • Si la requête échoue, external_identity.scim_api_failure
  • Si l'utilisateur est membre de l'un des groupes IdP qui sont mappés à des équipes, team.remove_member
  • Si l'appartenance d'un utilisateur à une organisation est gérée par l'IdP et qu'il est retiré de toutes les équipes mappées à des groupes IdP au sein de l'organisation, org.remove_member

Événements liés à la suppression définitive

  • external_identity.deprovision
  • user.remove_email
  • Si la demande réussit, external_identity.scim_api_success
  • Si la requête échoue, external_identity.scim_api_failure
  • Si l'utilisateur est membre de l'un des groupes IdP qui sont mappés à des équipes, team.remove_member
  • Si l'appartenance d'un utilisateur à une organisation est gérée par l'IdP et qu'il est retiré de toutes les équipes mappées à des groupes IdP au sein de l'organisation, org.remove_member

Événements liés à la réattribution

Lorsque vous réactivez un utilisateur, l'événement external_identity.update n'apparaît pas dans le journal d'audit. Les événements suivants s'affichent dans le journal d'audit :

  • user.unsuspend
  • user.remove_email
  • user.rename
  • external_identity.provision
  • Si la demande réussit, external_identity.scim_api_success
  • Si la requête échoue, external_identity.scim_api_failure
  • Si l’utilisateur est membre d’un groupe IdP provisionné par SCIM et que ce groupe est associé à une équipe au sein d’une organisation, org.add_member

Pour aller plus loin

  •         [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/provisioning-users-and-groups-with-scim-using-the-rest-api)