Note
O suporte ao OIDC (OpenID Connect) e à CAP (política de acesso condicional) nos Enterprise Managed Users só está disponível para o Microsoft Entra ID (antigo Azure AD).
Sobre o suporte a Políticas de Acesso Condicional
Quando a sua empresa usar o SSO do OIDC, o GitHub usará automaticamente as condições de IP da CAP (política de acesso condicional) do IdP para validar as interações com o GitHub quando os membros usarem a IU da Web ou alterarem os endereços IP e para cada autenticação com um personal access token ou uma chave SSH associada a uma conta de usuário.
Note
A proteção de CAP para sessões da Web atualmente está em versão prévia pública e poderá ser alterada.
Se o suporte ao IdP CAP já estiver habilitado para sua empresa, você poderá optar pela proteção estendida para sessões da Web nas configurações de "Authentication security" da empresa. Para habilitar esse recurso, sua empresa deve ter 1.000 membros ou menos, ativos ou suspensos.
O GitHub Enterprise Cloud dá suporte à CAP para qualquer empresa com usuários gerenciados em que o SSO do OIDC esteja habilitado. Os proprietários corporativos podem optar por usar essa configuração de lista de permissões de IP em vez da lista de permissões de IP do GitHub Enterprise Cloud, e podem fazer isso depois que o SSO do OIDC for configurado. Para obter mais informações sobre as listas de permissão de IP, confira Como restringir o tráfego de rede para sua empresa com uma lista de permissões de IP e Gerenciar endereços IP permitidos para sua organização.
- O GitHub Enterprise Cloud impõe as condições de IP do seu IdP, mas não pode impor as condições de conformidade do seu dispositivo.
- As políticas para autenticação multifator são aplicadas apenas no ponto de entrada no IdP.
Para obter mais informações sobre como usar o OIDC com o Enterprise Managed Users, confira Como configurar o OIDC para usuários empresariais gerenciados e Como migrar o SAML para o OIDC.
Sobre a CAP e as chaves de implantação
Uma chave de implantação é uma chave SSH que concede acesso a um repositório individual. Como as chaves de implantação não executam operações em nome de um usuário, as condições de IP da CAP não se aplicam a nenhuma solicitação autenticada com uma chave de implantação. Para saber mais, confira Gerenciar chaves de implantação.
Considerações sobre integrações e automações
GitHub envia o endereço IP de origem para seu IdP para validação em relação à sua CAP. Para garantir que ações e aplicativos não sejam bloqueados pela CAP do IdP, você precisará fazer alterações na configuração.
Warning
Se você usar o GitHub Enterprise Importer para migrar uma organização do sua instância do GitHub Enterprise Server, use uma conta de serviço isenta do CAP do Entra ID, caso contrário, a migração poderá ser bloqueada.
GitHub Actions
As ações que usam um personal access token provavelmente serão bloqueadas pela CAP do seu IdP. Recomendamos que os personal access token sejam criados por uma conta de serviço que fique isenta de controles de IP na CAP do seu IdP.
Se você não conseguir usar uma conta de serviço, outra opção para desbloquear ações que usam personal access token será permitir os intervalos de IP usados pelas GitHub Actions. Para saber mais, confira Sobre os endereços IP do GitHub.
GitHub Codespaces
Se a empresa usa o logon único de OIDC com CAP para restringir acesso por endereço IP, talvez os GitHub Codespaces não estejam disponíveis. O motivo é que os codespaces são criados com endereços IP dinâmicos, que provavelmente a CAP do IdP bloqueará. Outras políticas CAP também podem afetar a disponibilidade de GitHub Codespaces, dependendo da configuração específica da política.
O editor github.dev
O editor github.dev poderá não estar disponível se sua empresa usa SSO OIDC com CAP para restringir o acesso por endereços IP. Isso ocorre porque o github.dev depende de endereços IP dinâmicos, os quais provavelmente serõa bloqueados pelo CAP do IdP. Outras políticas CAP também podem afetar a disponibilidade de github.dev, dependendo da configuração específica da política.
GitHub Apps e OAuth apps
Quando o GitHub Apps e o OAuth apps conectarem um usuário e fizrem solicitações em nome dele, o GitHub enviará o endereço IP do servidor do aplicativo ao IdP para validação. Se o endereço IP do servidor do aplicativo não for validado pela CAP do IdP, a solicitação falhará.
Quando os GitHub Apps chamarem as APIs do GitHub que funcionam como o próprio aplicativo ou como uma instalação, essas chamadas não serão executadas em nome de um usuário. Como a CAP do IdP executa e aplica políticas a contas de usuário, essas solicitações de aplicativo não podem ser validadas na CAP e são sempre permitidas. Para obter mais informações sobre os GitHub Apps que se autenticam como eles mesmos ou como uma instalação, confira Sobre a autenticação com um GitHub App.
Entre em contato com os proprietários dos aplicativos que deseja usar, solicite seus intervalos de IP e configure a CAP do IdP para permitir o acesso desses intervalos de IP. Se não conseguir contatar os proprietários, você poderá examinar os logs de entrada do IdP para examinar os endereços IP vistos nas solicitações e, em seguida, inserir esses endereços na lista de permissões.
Se não quiser permitir todos os intervalos de IP para todos os aplicativos da sua empresa, você também poderá isentar os GitHub Apps instalados e os OAuth apps autorizados da lista de permissões do IdP. Se fizer isso, esses aplicativos seguirão funcionando independentemente do endereço IP de origem. Para saber mais, confira Aplicando políticas para configurações de segurança na sua empresa.
Leitura adicional
- Usar a condição de localização em uma política de Acesso condicional no Microsoft Learn