Dela via

Flexibla federerade identitetsuppgifter (förhandsversion)

  • Artikel

Flexibla federerade identitetsuppgifter är en avancerad funktion i Microsoft Entra-arbetsbelastnings-ID som förbättrar den befintliga modellen för federerade identitetsautentiseringsuppgifter. Den här artikeln beskriver hur dessa autentiseringsuppgifter fungerar, deras fördelar och aktuella begränsningar.

Flexibla federerade identitetsautentiseringsuppgifter tillåter användning av ett begränsat uttrycksspråk för matchning av inkommande subject anspråk och möjliggör inkludering av anpassade anspråk, vilket minskar hanteringskostnaderna och adresserar skalningsgränser i arbetsbelastningsidentitetsfederationen. Om du vill effektivisera autentiseringen för externa arbetsbelastningar med Microsoft Entra ger den här guiden dig de insikter och steg som krävs för att använda den här kraftfulla funktionen.

Varför ska du använda autentiseringsuppgifter för flexibel federerad identitet?

Det aktuella beteendet för federerade identitetsautentiseringsuppgifter inom arbetsbelastningsidentitetsfederationen kräver explicit matchning när du jämför de definierade subject, issueroch audience i den federerade identitetsautentiseringsuppgiften mot subject, issueroch audience som finns i token som skickas till Microsoft Entra. I kombination med den aktuella gränsen på 20 federerade identitetsautentiseringsuppgifter för ett visst program eller användartilldelad hanterad identitet kan skalningsgränserna nås snabbt.

Flexibla federerade identitetsuppgifter utökar den befintliga federerade identitetsautentiseringsmodellen genom att tillåta användning av ett begränsat uttrycksspråk vid matchning mot inkommande subject anspråk. Den kan också användas för att utöka auktoriseringsmodellen för federerade identitetsautentiseringsuppgifter utöver subject, issueroch audience anspråk genom att aktivera inkludering av vissa tillåtna anpassade anspråk i dina federerade identitetsautentiseringsuppgifter.

Flexibla federerade identitetsuppgifter kan bidra till att minska hanteringskostnaderna vid försök att autentisera externa arbetsbelastningar med Microsoft Entra och åtgärda skalningsgränserna i implementeringar av identitetsfederation för arbetsbelastningar.

Hur fungerar flexibla federerade identitetsuppgifter?

Flexibla federerade identitetsuppgifter ändrar inte baslinjefunktionerna som tillhandahålls av federerade identitetsuppgifter. Dessa förtroenderelationer används fortfarande för att ange vilken token från den externa IdP:t som ska vara betrodd av ditt program. I stället utökar de möjligheten för federerade identitetsautentiseringsuppgifter genom att aktivera scenarier som tidigare krävde att flera federerade identitetsuppgifter i stället skulle hanteras under en enda flexibel federerad identitetsautentisering. Några exempel är:

  • GitHub-lagringsplatser med olika arbetsflöden, var och en körs på en annan gren (eller används över grenar). Tidigare krävdes en unik federerad identitetsautentiseringsuppgift för var och en av de grenar där arbetsflöden kunde köras över. Med flexibla federerade identitetsuppgifter kan det här scenariot hanteras under en enda federerad identitetsautentiseringsuppgift.
  • Terraform cloud run_phases planer, som var och en kräver en unik federerad identitetsautentisering. Med flexibla federerade identitetsuppgifter kan detta hanteras under en enda flexibel federerad identitetsautentisering.
  • Återanvändbara GitHub Actions-arbetsflöden, där jokertecken kan användas i förhållande till GitHubs egna job_workflow_ref-krav.

Not

Stöd för flexibla federerade autentiseringsuppgifter för identiteter tillhandahålls för närvarande för matchning mot github-, GitLab- och Terraform Cloud-utfärdade token. Det här stödet finns endast för federerade identitetsautentiseringsuppgifter som konfigurerats för programobjekt för närvarande. Du kan bara skapa och hantera flexibla federerade identitetsuppgifter via Microsoft Graph eller Azure-portalen.

Flexibel federerad språkstruktur för identitetsautentiseringsuppgifter

Ett flexibelt federerat uttryck för autentiseringsuppgifter består av tre delar, anspråkssökningen, operatorn och jämförelsen. Se följande tabell för en uppdelning av varje del:

Namn Beskrivning Exempel
Kravsökning Anspråkssökningen måste följa mönstret för claims[‘<claimName>’] claims['sub']
Operatör Operatordelen måste bara vara operatornamnet, avgränsat från sökningen av anspråk och jämförelseobjektet med ett enda blanksteg. matches
Jämförelseobjekt Komparatorn innehåller det du tänker jämföra anspråket som anges i uppslaget mot – det måste finnas inom enskilda citattecken. 'repo:contoso/contoso-repo:ref:refs/heads/*'

Tillsammans skulle ett exempel på ett flexibelt federerat uttryck för autentiseringsuppgifter se ut som följande JSON-objekt:

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

Konfigurera federerade identitetsuppgifter via Microsoft Graph

För att hantera funktionen för flexibla federerade identitetsautentiseringsuppgifter utökas den federatedIdentityCredentials resursen med en ny claimsMatchingExpression egenskap. Dessutom kan egenskapen subject nu vara null. Egenskaperna claimsMatchingExpression och subject är ömsesidigt uteslutande, så du kan inte definiera båda inom en federerad identitetsautentiseringsuppgift.

  • audiences: Målgruppen som kan visas i den externa token. Det här fältet är obligatoriskt och ska anges till api://AzureADTokenExchange för Microsoft Entra-ID. Det står vad Microsofts identitetsplattform ska acceptera i det aud anspråket i den inkommande token. Det här värdet representerar Microsoft Entra-ID i din externa identitetsprovider och har inget fast värde mellan identitetsprovidrar . Du kan behöva skapa en ny programregistrering i din IdP för att fungera som målgrupp för denna token.
  • issuer: URL:en för den externa identitetsprovidern. Måste matcha utfärdaranspråket för den externa token som utbyts.
  • subject: Identifieraren för den externa programvaruarbetsbelastningen inom den externa identitetsprovidern. Precis som målgruppsvärdet har det inget fast format, eftersom varje IdP använder sitt eget – ibland ett GUID, ibland en kolonavgränsad identifierare, ibland godtyckliga strängar. Detta värde måste matcha anspråk sub i token som presenteras för Microsoft Entra ID. Om subject har definierats måste claimsMatchingExpression anges till null.
  • name: En unik sträng för att identifiera autentiseringsuppgifterna. Den här egenskapen är en alternativ nyckel och värdet kan användas för att referera till federerade identitetsautentiseringsuppgifter via GET- och UPSERT- åtgärder.
  • claimsMatchingExpression: en ny komplex typ som innehåller två egenskaper, value och languageVersion. Värdet används för att definiera uttrycket och languageVersion används för att definiera den version av FFL (Flexible Federated Identity Credential Expression Language) som används. languageVersion ska alltid anges till 1. Om claimsMatchingExpression har definierats måste subject anges till null.

Flexibel språkfunktion för federerade identitetsautentiseringsuppgifter

Flexibla federerade identitetshandlingar stöder för närvarande användning av vissa operatörer hos de aktiverade utfärdarna. Enkla citattecken tolkas som escape-tecken i det flexibla federerade uttrycksspråket för identitetsautentiseringsuppgifter.

Operatör Beskrivning Exempel
matches Aktiverar användning av ett tecken (som anges av ?) och flera tecken (anges av *) jokerteckenmatchning för det angivna anspråket • “claims[‘sub’] matches ‘repo:contoso/contoso-repo:ref:refs/heads/*’”
• “claims[‘sub’] matches ‘repo:contoso/contoso-repo-*:ref:refs/heads/????’”
eq Används för explicit matchning mot ett angivet anspråk • “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’”
and Boolesk operator för att kombinera uttryck mot flera anspråk • “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’”

Utfärdar-URL:er, anspråk som stöds och operatorer per plattform

Beroende på vilken plattform du använder måste du implementera olika URL:er för utfärdare, anspråk och operatörer. Använd följande flikar för att välja din valda plattform.

Utfärdar-URL:er som stöds: https://token.actions.githubusercontent.com

Anspråk och operatorer som stöds per anspråk:

  • Anspråk sub stöder operatorer eq och matches
  • Anspråk job_workflow_ref understödjer operatorerna eq och matches

Azure CLI-, Azure PowerShell- och Terraform-leverantörer

Explicit stöd för flexibla federerade identitetsautentiseringsuppgifter finns ännu inte i Azure CLI, Azure PowerShell eller Terraform-leverantörer. Om du försöker konfigurera en flexibel federerad identitetsautentiseringsuppgift med något av dessa verktyg visas ett fel. Om du konfigurerar en flexibel federerad identitetsautentiseringsuppgift via antingen Microsoft Graph eller Azure-portalen och försöker läsa den flexibla federerade identitetsautentiseringsuppgiften med något av dessa verktyg visas dessutom ett fel.

Du kan använda Azure CLI:s az rest-metod för att göra REST API-begäranden för skapande och hantering av flexibla federerade identitetsautentiseringsuppgifter.

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

Relaterat innehåll