Partilhar via

Credenciais flexíveis de identidade federada (pré-visualização)

  • Artigo

As credenciais flexíveis de identidade federada são um recurso avançado do Microsoft Entra Workload ID que aprimora o modelo de credenciais de identidade federada existente. Este artigo explica como essas credenciais funcionam, seus benefícios e limitações atuais.

As credenciais flexíveis de identidade federada permitem o uso de uma linguagem de expressão restrita para corresponder reivindicações de entrada subject e possibilitar a inclusão de reivindicações personalizadas, ajudando a reduzir a sobrecarga de gestão e a lidar com os limites de escala na federação de identidade de carga de trabalho. Se você está procurando simplificar a autenticação para cargas de trabalho externas com o Microsoft Entra, este guia fornece as informações e as etapas necessárias para usar esse poderoso recurso.

Por que usar credenciais de identidade federada flexíveis?

O comportamento atual das credenciais de identidade federada no âmbito da federação de identidades para cargas de trabalho requer uma correspondência explícita ao comparar os subject, issuere audience definidos na credencial de identidade federada com os subject, issuere audience contidos no token enviado ao Microsoft Entra. Quando combinado com o limite atual de 20 credenciais de identidade federada para um determinado aplicativo ou identidade gerenciada atribuída pelo usuário, os limites de escala podem ser atingidos rapidamente.

As credenciais flexíveis de identidade federada expandem o modelo existente de credenciais de identidade federada, permitindo a utilização de uma linguagem de expressões restrita ao corresponder a reclamações de entrada subject. Ele também pode ser usado para estender o modelo de autorização de credenciais de identidade federada além das declarações subject, issuere audience, permitindo a inclusão de determinadas declarações personalizadas permitidas em suas credenciais de identidade federada.

As credenciais flexíveis de identidade federada podem ajudar a reduzir a sobrecarga de gerenciamento ao tentar autenticar cargas de trabalho externas com o Microsoft Entra, além de abordar os limites de escala nas implementações de federação de identidades de carga de trabalho.

Como funcionam as credenciais de identidade federada flexíveis?

As credenciais flexíveis de identidade federada não alteram a funcionalidade de linha de base fornecida pelas credenciais de identidade federada. Essas relações de confiança ainda são usadas para indicar qual token do IdP externo deve ser confiável pelo seu aplicativo. Em vez disso, eles estendem a capacidade de credenciais de identidade federada permitindo que cenários que anteriormente exigiam várias credenciais de identidade federada sejam gerenciados sob uma única credencial de identidade federada flexível. Alguns exemplos incluem:

  • Repositórios do GitHub com vários fluxos de trabalho, cada um em execução em uma ramificação diferente (ou sendo usado entre ramificações). Anteriormente, uma credencial de identidade federada exclusiva era necessária para cada uma das ramificações nas quais os fluxos de trabalho podiam ser executados. Com credenciais de identidade federada flexíveis, esse cenário pode ser gerenciado sob uma única credencial de identidade federada.
  • Os planos do Terraform Cloud run_phases, cada um requer uma credencial de identidade federada exclusiva. Com credenciais de identidade federada flexíveis, isso pode ser gerenciado sob uma única credencial de identidade federada flexível.
  • Fluxos de trabalho reutilizáveis ​​de ações do GitHub, onde curingas podem ser usados ​​contra a reivindicação job_workflow_ref personalizada do GitHub.

Observação

O suporte flexível a credenciais de identidade federada é atualmente fornecido para correspondência com tokens emitidos pelo GitHub, GitLab e Terraform Cloud. Esse suporte existe apenas para credenciais de identidade federada configuradas em objetos de aplicativo atualmente. Você só pode criar e gerenciar credenciais de identidade federada flexíveis por meio do Microsoft Graph ou do portal do Azure.

Estrutura flexível da linguagem de credenciais de identidade federada

Uma expressão flexível de credenciais de identidade federada é composta por três partes: a pesquisa de declaração, o operador e a comparação. Consulte o quadro seguinte para obter uma discriminação de cada parte:

Nome Descrição Exemplo
Pesquisa de reivindicações A pesquisa de sinistro deve seguir o padrão de claims[‘<claimName>’] claims['sub']
Operador A parte do operador deve ser apenas o nome do operador, separado da pesquisa de declaração e comparação por um único espaço matches
Comparando A comparação contém o que você pretende comparar a declaração especificada na pesquisa com – ela deve estar contida entre aspas simples 'repo:contoso/contoso-repo:ref:refs/heads/*'

Juntos, um exemplo de expressão de credenciais de identidade federada flexível seria semelhante ao seguinte objeto JSON:

"claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*'."

Configurar credenciais de identidade federada por meio do Microsoft Graph

Para acomodar a funcionalidade flexível de credenciais de identidade federada, o recurso federatedIdentityCredentials está sendo estendido com uma nova propriedade claimsMatchingExpression. Além disso, a propriedade subject agora é anulável. As propriedades claimsMatchingExpression e subject são mutuamente exclusivas, portanto, não é possível definir ambas em uma credencial de identidade federada.

  • audiences: A audiência que pode aparecer no token externo. Este campo é obrigatório e deve ser definido como api://AzureADTokenExchange para Microsoft Entra ID. Indica o que a plataforma de identidade da Microsoft deve aceitar na reivindicação aud no token de entrada. Esse valor representa a ID do Microsoft Entra no seu fornecedor de identidade externo e não tem um valor fixo entre os fornecedores de identidade - poderá ser necessário criar um novo registo de aplicação no seu IdP para servir como o destinatário deste token.
  • issuer: A URL do provedor de identidade externo. Deve corresponder à declaração do emissor do token externo que está sendo trocado.
  • subject: O identificador da carga de trabalho de software externo dentro do provedor de identidade externo. Como o valor de audiência, ele não tem formato fixo, pois cada IdP usa seu próprio - às vezes um GUID, às vezes um identificador delimitado por dois pontos, às vezes cadeias de caracteres arbitrárias. O valor aqui deve corresponder à declaração de sub dentro do token apresentado ao Microsoft Entra ID. Se subject estiver definido, claimsMatchingExpression deve ser definido como null.
  • name: Uma cadeia de caracteres exclusiva para identificar a credencial. Essa propriedade é uma chave alternativa e o valor pode ser usado para fazer referência à credencial de identidade federada por meio das operações GET e UPSERT.
  • claimsMatchingExpression: um novo tipo complexo contendo duas propriedades, value e languageVersion. O valor é usado para definir a expressão e languageVersion é usado para definir a versão da FFL (linguagem de expressão de credenciais de identidade federada) flexível que está sendo usada. languageVersion deve ser sempre definido como 1. Se claimsMatchingExpression estiver definido, subject deve ser definido como null.

Funcionalidade flexível de linguagem de expressão de credenciais de identidade federada

Atualmente, as credenciais flexíveis de identidade federada suportam o uso de alguns operadores nos emissores habilitados. Aspas simples são interpretadas como caracteres de escape na linguagem flexível de expressão de credenciais de identidade federada.

Operador Descrição Exemplo
matches Permite o uso de correspondência com caractere curinga de um único caractere (indicado por ?) e de múltiplos caracteres (indicado por *) para a afirmação especificada. • “claims[‘sub’] matches ‘repo:contoso/contoso-repo:ref:refs/heads/*’”
• “claims[‘sub’] matches ‘repo:contoso/contoso-repo-*:ref:refs/heads/????’”
eq Usado para corresponder explicitamente a uma reivindicação especificada • “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’”
and Operador booleano para combinar expressões contra várias declarações • “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’ and claims[‘job_workflow_ref’] matches ‘foo-org/bar-repo /.github/workflows/*@refs/heads/main’”

URLs do emissor, declarações suportadas e operadores por plataforma

Dependendo da plataforma que você está usando, você precisa implementar diferentes URLs, declarações e operadores do emissor. Utilize as seguintes guias para selecionar a sua plataforma desejada.

URLs de emissor suportados: https://token.actions.githubusercontent.com

Reclamações suportadas e operadores por reclamação:

  • A Claim sub apoia operadores eq e matches
  • Claim job_workflow_ref suporta os operadores eq e matches

Provedores de CLI do Azure, Azure PowerShell e Terraform

O suporte explícito e flexível a credenciais de identidade federada ainda não existe nos provedores de CLI do Azure, Azure PowerShell ou Terraform. Se você tentar configurar uma credencial de identidade federada flexível com qualquer uma dessas ferramentas, verá um erro. Além disso, se você configurar uma credencial de identidade federada flexível por meio do Microsoft Graph ou do portal do Azure e tentar ler essa credencial de identidade federada flexível com qualquer uma dessas ferramentas, verá um erro.

Você pode usar o método az rest da CLI do Azure para fazer solicitações de API REST para criação e gerenciamento flexíveis de credenciais de identidade federada.

az rest --method post \
    --url https://graph.microsoft.com/beta/applications/{objectId}/federatedIdentityCredentials
    --body "{'name': 'FlexFic1', 'issuer': 'https://token.actions.githubusercontent.com', 'audiences': ['api://AzureADTokenExchange'], 'claimsMatchingExpression': {'value': 'claims[\'sub\'] matches \'repo:contoso/contoso-org:ref:refs/heads/*\'', 'languageVersion': 1}}"

Conteúdo relacionado