Skip to main content

À propos de la prise en charge de la stratégie d’accès conditionnel de votre fournisseur d’identité

Lorsque votre entreprise utilise l’OIDC SSO, GitHub peut valider l’accès à votre entreprise et à ses ressources à l’aide de la stratégie d’accès conditionnel (CAP) de votre fournisseur d’identité.

Qui peut utiliser cette fonctionnalité ?

Enterprise Managed Users est disponible pour les nouveaux comptes d’entreprise sur GitHub Enterprise Cloud. Consultez À propos de Enterprise Managed Users.

Remarque

La prise en charge d'OpenID Connect (OIDC) et de la politique d'accès conditionnel (CAP) pour Enterprise Managed Users n'est disponible que pour Microsoft Entra ID (anciennement Azure AD).

À propos de la prise en charge des stratégies d’accès conditionnel

Lorsque votre entreprise utilise l'authentification unique OIDC, GitHub utilisera automatiquement la politique d'accès conditionnel (CAP) de votre fournisseur d'identité pour valider les interactions avec GitHub lorsque les membres utilisent l’interface utilisateur web ou modifient les adresses IP, et pour chaque authentification avec une clé SSH associée à un compte d'utilisateur.

Remarque

La protection CAP pour les sessions web est actuellement dans préversion publique et peut changer.

Si le support CAP de l'IdP est déjà activé pour votre entreprise, vous pouvez opter pour une protection étendue des sessions web à partir des paramètres « Sécurité de l'authentification » de votre entreprise. Lorsque la protection de session web est activée et que les conditions de l’adresse IP d’un utilisateur ne sont pas satisfaites, il peut consulter et filtrer toutes les ressources appartenant à l’utilisateur, mais ne peut pas voir les détails des résultats pour les notifications, les recherches, les tableaux de bord personnels ou les référentiels en vedette.

GitHub prend en charge CAP pour tout entreprise avec utilisateurs managés pour lequel l’authentification unique OIDC est activée. Les propriétaires d’entreprise peuvent choisir d’utiliser cette configuration de liste d’autorisation IP au lieu de la liste d’autorisation IP de GitHub, et peuvent le faire une fois l’authentification unique OIDC (SSO) configurée. Pour plus d’informations sur les listes d’adresses IP autorisées, consultez « Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées » et « Gestion des adresses IP autorisées pour votre organisation ».

  • GitHub applique les conditions IP de votre fournisseur d’identité, mais ne peut pas appliquer les conditions de conformité de votre appareil.
  • Les stratégies d'authentification multifacteur ne sont appliquées qu’au moment de la connexion au fournisseur d’identité.

Pour plus d’informations sur l’utilisation d’OIDC avec Enterprise Managed Users, consultez Configuration d’OIDC pour les utilisateurs managés par l’entreprise et Migration de SAML vers OIDC.

À propos de CAP et de clés de déploiement

Une clé de déploiement est une clé SSH qui accorde l’accès à un référentiel individuel. Étant donné que les clés de déploiement n’effectuent pas d’opérations pour le compte d’un utilisateur, les conditions IP CAP ne s’appliquent pas aux demandes authentifiées avec un clé de déploiement. Pour plus d’informations, consultez « Gestion des clés de déploiement ».

Considérations relatives aux intégrations et aux automatisations

GitHub envoie l’adresse IP source à votre IdP afin de la valider au regard de votre CAP. Pour vous assurer que les actions et les applications ne sont pas bloquées par la stratégie d’autorisation de connexion de votre fournisseur d’identité, vous devrez apporter des modifications à votre configuration.

Avertissement

Si vous utilisez GitHub Enterprise Importer pour migrer une organisation depuis votre instance GitHub Enterprise Server, veillez à utiliser un compte de service exempté de la stratégie d’accès conditionnel d’Entra ID, sinon votre migration peut être bloquée.

GitHub Actions

Les actions qui utilisent personal access token seront probablement bloquées par la CAP de votre IdP. Nous vous recommandons que les personal access token soient créés par un compte de service, qui sera ensuite exempté des contrôles IP dans la CAP de votre IdP.

Si vous ne parvenez pas à utiliser un compte de service, une autre option pour débloquer des actions qui utilisent personal access tokenest d’autoriser les plages d’adresses IP utilisées par GitHub Actions. Pour plus d’informations, consultez « À propos des adresses IP de GitHub ».

GitHub Codespaces

GitHub Codespaces peut ne pas être disponible si votre entreprise utilise l’OIDC SSO avec CAP pour restreindre l’accès par adresses IP. En effet, les codespaces sont créés avec des adresses IP dynamiques qui seront probablement bloquées par la stratégie d’accès conditionnel de votre fournisseur d’identité. D’autres stratégies CAP peuvent également affecter la disponibilité de GitHub Codespaces, en fonction de la configuration spécifique de la stratégie.

Éditeur github.dev

L’éditeur github.dev peut ne pas être disponible si votre entreprise utilise l’OIDC SSO avec CAP pour restreindre l’accès par adresses IP. C’est parce que github.dev s’appuie sur des adresses IP dynamiques, que la stratégie CAP de votre IdP bloquera probablement. D’autres stratégies CAP peuvent également affecter la disponibilité de github.dev, selon le paramétrage spécifique de la stratégie concernée.

GitHub Apps et OAuth apps

Quand GitHub Apps et OAuth apps connectent un utilisateur et effectuent des requêtes au nom de cet utilisateur, GitHub enverra l’adresse IP du serveur de l’application à votre fournisseur d’identité (IdP) pour validation. Si l’adresse IP du serveur de l’application n’est pas validée par la stratégie d’autorisation de connexion de votre fournisseur d’identité, la demande échouera.

Lorsque les GitHub Apps API d’appel GitHub agissent en tant qu’application elle-même ou en tant qu’installation, ces appels ne sont pas effectués pour le compte d’un utilisateur. Étant donné que la stratégie d’autorisation de connexion de votre fournisseur d’identité exécute des stratégies et les applique à des comptes d’utilisateur, ces requêtes d’application ne peuvent pas être validées par rapport à la stratégie d’autorisation de connexion et elles sont toujours autorisées. Pour plus d’informations sur la manière de s’authentifier GitHub Apps en tant que soi-même ou en tant qu’installation, consultez À propos de l’authentification avec une application GitHub.

Vous pouvez contacter les propriétaires des applications que vous souhaitez utiliser, demander leurs plages d’adresses IP et configurer la stratégie d’autorisation de connexion de votre fournisseur d’identité pour autoriser l’accès à partir de ces plages d’adresses IP. Si vous ne parvenez pas à contacter les propriétaires, vous pouvez consulter les journaux d’ouverture de session de votre fournisseur d’identité pour voir les adresses IP qui ont fait l’objet des demandes, puis les inscrire sur une liste d’autorisation.

Si vous ne souhaitez pas autoriser toutes les plages d’adresses IP pour l’ensemble des applications de votre entreprise, vous pouvez également exclure de la liste d’autorisation de l’IdP les éléments installés GitHub Apps et autorisés OAuth apps. Si vous le faites, ces applications continueront de fonctionner quelle que soit l’adresse IP d’origine. Pour plus d’informations, consultez « Application de stratégies pour les paramètres de sécurité dans votre entreprise ».

Pour aller plus loin