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
activedans leur identité SCIM liée stockée est mise à jour deTrueà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 SCIM | Déclencheur de la suppression temporaire |
|---|---|
| API REST | Une 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 ID | Un 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. |
| Okta | Un 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. |
| PingFederate | L’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 SCIM | Déclencheur du déprovisionnement forcé |
|---|---|
| API REST | Une requête DELETE est envoyée à /scim/v2/Users/{scim_user_id}. |
| Entra ID | La 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. |
| Okta | N/A. Okta n’envoie pas d’appels de déprovisionnement complet. |
| PingFederate | Si 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 SCIM | Action pour réapprovisionner les utilisateurs |
|---|---|
| Entra ID | Ré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 ». |
| Okta | Réactivez le compte ou réaffectez l’utilisateur à l’application, soit directement, soit via un groupe. |
| PingFederate | Ré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 REST | Envoyez 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.suspenduser.remove_emailuser.renameexternal_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.deprovisionuser.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.unsuspenduser.remove_emailuser.renameexternal_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)