Delen via


Flexibele federatieve identiteitsinloggegevens (preview)

Flexibele federatieve identiteitsreferenties zijn een geavanceerde functie van De Workload-id van Microsoft Entra waarmee het bestaande model voor federatieve identiteitsreferenties wordt verbeterd. In dit artikel wordt uitgelegd hoe deze referenties werken, wat hun voordelen zijn en wat de huidige beperkingen zijn.

Flexibele federatieve identiteitsreferenties maken het gebruik van een beperkt expressietaal mogelijk voor het matchen van binnenkomende subject claims en de opname van aangepaste claims, waardoor de beheeroverhead wordt verminderd en schaalbeperkingen in de identiteitsfederatie van workloads worden aangepakt. Als u de verificatie voor externe workloads met Microsoft Entra wilt stroomlijnen, biedt deze handleiding u de benodigde inzichten en stappen voor het gebruik van deze krachtige functie.

Waarom flexibele federatieve identiteitsreferenties gebruiken?

Het huidige gedrag van federatieve identiteitsreferenties binnen de workload-identiteitsfederatie vereist expliciete overeenstemming bij het vergelijken van de gedefinieerde subject, issueren audience in de federatieve identiteitsreferentie met de subject, issueren audience die zijn opgenomen in het token dat naar Microsoft Entra is verzonden. In combinatie met de huidige limiet van 20 federatieve identiteitsreferenties voor een bepaalde toepassing of door de gebruiker toegewezen beheerde identiteit, kunnen schaallimieten snel worden bereikt.

Flexibele federatieve identiteitsreferenties breiden het bestaande federatieve identiteitsreferentiemodel uit door het gebruik van een taal met beperkte expressie toe te staan wanneer deze overeenkomt met binnenkomende subject claims. Het kan ook worden gebruikt om het autorisatiemodel voor federatieve identiteitsreferenties uit te breiden buiten de subject, issueren audience claims door het inschakelen van bepaalde toegestane aangepaste claims binnen uw federatieve identiteitsreferenties.

Flexibele federatieve identiteitsreferenties kunnen u helpen de beheeroverhead te verminderen bij het verifiëren van externe workloads met Microsoft Entra en de schaallimieten in implementaties van workloadidentiteitsfederaties te verhelpen.

Hoe werken flexibele federatieve identiteitsreferenties?

Flexibele federatieve identiteitsreferenties wijzigen niet de basislijnfunctionaliteit die wordt geboden door federatieve identiteitsreferenties. Deze vertrouwensrelaties worden nog steeds gebruikt om aan te geven welk token van de externe IdP moet worden vertrouwd door uw toepassing. In plaats daarvan breiden ze de mogelijkheid van federatieve identiteitsreferenties uit door scenario's in te schakelen waarvoor eerder meerdere federatieve identiteitsreferenties moesten worden beheerd onder één flexibele federatieve identiteitsreferentie. Enkele voorbeelden zijn:

  • GitHub-opslagplaatsen met verschillende werkstromen, die elk worden uitgevoerd op een andere vertakking (of worden gebruikt in verschillende vertakkingen). Voorheen was een uniek federatief identiteitsbewijs vereist voor elk van de takken waarin werkstromen konden worden uitgevoerd. Met flexibele federatieve identiteitsreferenties kan dit scenario worden beheerd onder één federatieve identiteitsreferentie.
  • Terraform Cloud run_phases-plannen, waarvoor elk een unieke federatieve identiteitsreferentie vereist. Met flexibele federatieve identiteitsreferenties kan dit worden beheerd onder één flexibele federatieve identiteitsreferentie.
  • Herbruikbare GitHub Actions-werkstromen, waarbij jokertekens kunnen worden gebruikt voor de aangepaste job_workflow_ref claim van GitHub.

Notitie

Ondersteuning voor flexibele federatieve identiteitsreferenties is momenteel beschikbaar voor overeenkomsten met door GitHub, GitLab en Terraform Cloud uitgegeven tokens. Deze ondersteuning bestaat alleen voor federatieve identiteitsreferenties die momenteel zijn geconfigureerd voor toepassingsobjecten. U kunt alleen flexibele federatieve identiteitsreferenties maken en beheren via Microsoft Graph of Azure Portal.

Flexibele taalstructuur voor federatieve identiteitreferenties

Een flexibele expressie voor federatieve identiteitsreferenties bestaat uit drie delen, de claimzoekactie, de operator en de comparand. Raadpleeg de volgende tabel voor een uitsplitsing van elk onderdeel:

Naam Beschrijving Voorbeeld
Claim opzoeken De claimzoekactie moet het patroon van claims[‘<claimName>’] volgen claims['sub']
Bediener Het operatorgedeelte moet alleen de operatornaam zijn, gescheiden van de claimzoekactie en comparand door één spatie matches
Comparand De comparand bevat wat u van plan bent om de claim te vergelijken die is opgegeven in de zoekactie - deze moet binnen enkele aanhalingstekens staan 'repo:contoso/contoso-repo:ref:refs/heads/*'

Een voorbeeld van een flexibele expressie voor federatieve identiteitsreferenties ziet eruit als het volgende JSON-object:

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

Federatieve identiteitsreferenties instellen via Microsoft Graph

Voor de flexibele functionaliteit voor federatieve identiteitsreferenties wordt de federatedIdentityCredentials resource uitgebreid met een nieuwe claimsMatchingExpression eigenschap. Bovendien is de eigenschap subject nu nullable. De eigenschappen claimsMatchingExpression en subject sluiten elkaar wederzijds uit, zodat u niet beide kunt definiëren binnen een federatieve identiteitsreferentie.

  • audiences: de doelgroep die in het externe token kan worden weergegeven. Dit veld is verplicht en moet worden ingesteld op api://AzureADTokenExchange voor Microsoft Entra-id. Er wordt opgegeven wat Microsoft Identity Platform moet accepteren in de aud claim in het binnenkomende token. Deze waarde vertegenwoordigt Microsoft Entra-id in uw externe id-provider en heeft geen vaste waarde voor id-providers. Mogelijk moet u een nieuwe toepassingsregistratie maken in uw IdP om als doelgroep van dit token te fungeren.
  • issuer: de URL van de externe id-provider. Moet overeenkomen met de claim van de uitgever van het externe token dat wordt uitgewisseld.
  • subject: De identificator van de externe softwarewerkbelasting binnen de externe identiteitsprovider. Net als de waarde voor de doelgroep heeft het geen vaste indeling, omdat elke IdP hun eigen indeling gebruikt - soms wordt een GUID gebruikt, soms een met dubbele punten gescheiden id, en soms willekeurige tekenreeksen. De waarde hier moet overeenkomen met de sub claim binnen het token dat aan Microsoft Entra-id wordt gepresenteerd. Als subject is gedefinieerd, moet claimsMatchingExpression worden ingesteld op null.
  • name: een unieke tekenreeks om de referentie te identificeren. Deze eigenschap is een alternatieve sleutel en de waarde kan worden gebruikt om te verwijzen naar de federatieve identiteitsreferentie via de GET- en UPSERT- bewerkingen.
  • claimsMatchingExpression: een nieuw complex type met twee eigenschappen, value en languageVersion. Waarde wordt gebruikt om de expressie te definiëren en languageVersion wordt gebruikt om de versie te definiëren van de flexibele FFL (Federated Identity Credential Expression Language) die wordt gebruikt. languageVersion moet altijd worden ingesteld op 1. Als claimsMatchingExpression is gedefinieerd, moet subject worden ingesteld op null.

Flexibele functionaliteit voor expressietaal voor federatieve identiteitreferenties

Flexibele federatieve identiteitsbewijzen ondersteunen momenteel het gebruik van enkele dienstverleners bij de ingeschakelde uitgevers. Enkele aanhalingstekens worden geïnterpreteerd als escapetekens binnen de flexibele expressietaal voor federatieve identiteitsbewijzen.

Bediener Beschrijving Voorbeeld
matches Hiermee schakelt u het gebruik van jokertekens met één teken (aangeduid door ?) en jokertekens met meerdere tekens (aangeduid door *) in voor de opgegeven claim “claims[‘sub’] matches ‘repo:contoso/contoso-repo:ref:refs/heads/*’”
“claims[‘sub’] matches ‘repo:contoso/contoso-repo-*:ref:refs/heads/????’”
eq Wordt gebruikt om expliciet overeen te komen met een bepaalde claim “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’”
and Booleaanse operator voor het combineren van uitdrukkingen tegen meerdere claims “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’”

URL's van verleners, ondersteunde claims en operators per platform

Afhankelijk van het platform dat u gebruikt, moet u verschillende verleners-URL's, claims en operators implementeren. Gebruik de volgende tabbladen om het gekozen platform te selecteren.

Ondersteunde URL's voor verleners: https://token.actions.githubusercontent.com

Ondersteunde claims en operators per claim:

  • Claim sub ondersteunt operators eq en matches
  • Claim job_workflow_ref ondersteunt operators eq en matches

Azure CLI-, Azure PowerShell- en Terraform-providers

Expliciete ondersteuning voor federatieve identiteitsreferenties bestaat nog niet binnen Azure CLI-, Azure PowerShell- of Terraform-providers. Als u probeert een flexibele federatieve identiteitsreferentie te configureren met een van deze hulpprogramma's, ziet u een fout. Als u bovendien een flexibele federatieve identiteitsreferentie configureert via Microsoft Graph of Azure Portal en probeert deze flexibele federatieve identiteitsreferentie te lezen met een van deze hulpprogramma's, ziet u een fout.

U kunt de az rest methode van Azure CLI gebruiken om REST API-aanvragen te maken voor het flexibel maken en beheren van federatieve identiteitsreferenties.

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}}"