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 la CAP pour tout entreprise avec utilisateurs managés où le SSO OIDC est activé. Les propriétaires d'entreprises peuvent choisir d'utiliser cette configuration de liste d'adresses IP autorisées au lieu de la liste d'adresses IP autorisées de GitHub, et peuvent le faire une fois que le SSO OIDC est configuré. 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 IdP 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 d’origine à votre fournisseur d’identité pour validation par rapport à votre stratégie d’autorisation de connexion. 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 un personal access token seront probablement bloquées par la stratégie d’accès conditionnel de votre fournisseur d’identité. Nous recommandons que les personal access token soient créés par un compte de service qui est ensuite exempté des contrôles d’IP dans la stratégie d’accès conditionnel de votre fournisseur d’identité.
Si vous ne pouvez pas utiliser un compte de service, une autre option pour débloquer les actions qui utilisent des personal access token consiste à autoriser les plages d’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’authentification unique OIDC avec une stratégie d’accès conditionnel 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 d’accès conditionnel peuvent également affecter la disponibilité de GitHub Codespaces, en fonction de la configuration spécifique de la stratégie.
L’éditeur github.dev
L'éditeur github.dev peut ne pas être disponible si votre entreprise utilise OIDC SSO avec CAP pour restreindre l'accès par adresses IP. En effet, github.dev s'appuie sur des adresses IP dynamiques que le CAP de votre IdP risque de bloquer. D'autres stratégies PAC peuvent également affecter la disponibilité de github.dev, en fonction de la configuration spécifique de la stratégie.
GitHub Apps et OAuth apps
Quand des GitHub Apps et des OAuth apps connectent un utilisateur et font des demandes au nom de cet utilisateur, GitHub envoie l’adresse IP du serveur de l’application à votre fournisseur d’identité 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.
Quand des GitHub Apps appellent des API GitHub faisant office d’application elle-même ou d’installation, ces appels ne sont pas effectués au nom 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 l’authentification des GitHub Apps en tant qu’elles-mêmes ou en tant qu’installations, 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 toutes les applications de votre entreprise, vous pouvez également exempter les GitHub Apps installées et les OAuth apps autorisées de la liste d’autorisations du fournisseur d’identité. 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 ».