Condividi tramite

Credenziali di identità federate flessibili (anteprima)

  • Articolo

Le credenziali di identità federate flessibili sono una caratteristica avanzata del Workload ID di Microsoft Entra che migliora il modello esistente di credenziali di identità federate. Questo articolo illustra il funzionamento di queste credenziali, i relativi vantaggi e le limitazioni correnti.

Le credenziali flessibili di identità federata permettono l'uso di un linguaggio di espressione limitato per la corrispondenza delle attestazioni subject in entrata, e consentono l'inclusione di attestazioni personalizzate. Questo aiuta a ridurre il sovraccarico di gestione e affrontare i limiti di scalabilità nella federazione delle identità dei carichi di lavoro. Se si sta cercando di semplificare l'autenticazione per carichi di lavoro esterni con Microsoft Entra, questa guida fornisce le informazioni dettagliate e i passaggi necessari per usare questa potente funzionalità.

Perché usare credenziali di identità federate flessibili?

Il comportamento corrente delle credenziali dell'identità federata nell'ambito della federazione dell'identità di carico di lavoro richiede una corrispondenza esplicita quando si confrontano i subject, issuere audience definiti nelle credenziali dell'identità federata con i subject, issuere audience contenuti nel token inviato a Microsoft Entra. Se combinato con il limite corrente di 20 credenziali di identità federate per una determinata applicazione o identità gestita assegnata dall'utente, è possibile raggiungere rapidamente i limiti di scalabilità.

Le credenziali di identità federate flessibili estendono il modello delle credenziali di identità federata esistente, consentendo l'uso di un linguaggio espressivo ristretto per la corrispondenza con le attestazioni in ingresso subject. Può essere usato anche per ampliare il modello di autorizzazione delle credenziali di identità federata oltre le attestazioni subject, issuere audience, abilitando l'inclusione di particolari attestazioni personalizzate autorizzate all'interno delle credenziali di identità federata.

Le credenziali di identità federate flessibili consentono di ridurre il sovraccarico di gestione quando si tenta di autenticare carichi di lavoro esterni con Microsoft Entra e di soddisfare i limiti di scalabilità nelle implementazioni della federazione delle identità del carico di lavoro.

Come funzionano le credenziali di identità federate flessibili?

Le credenziali di identità federate flessibili non modificano la funzionalità di base fornita dalle credenziali di identità federate. Queste relazioni di fiducia vengono ancora usate per indicare quale token del provider di identità esterno debba essere considerato attendibile dalla tua applicazione. Estende invece la possibilità di credenziali di identità federate abilitando scenari che in precedenza richiedevano la gestione di più credenziali di identità federate in un'unica credenziale di identità federata flessibile. Alcuni esempi includono:

  • Repository GitHub con vari flussi di lavoro, ognuno in esecuzione in un ramo diverso (o utilizzato attraverso i rami). In precedenza, era necessaria una credenziale di identità federata univoca per ogni ramo in cui i flussi di lavoro potevano essere eseguiti. Con credenziali di identità federate flessibili, questo scenario può essere gestito con una singola credenziale di identità federata.
  • I piani cloud di Terraform run_phases, ciascuno dei quali richiede una credenziale di identità federata univoca. Con le credenziali di identità federate flessibili, questa può essere gestita con una singola credenziale di identità federata flessibile.
  • Flussi di lavoro riutilizzabili di GitHub Actions, in cui i caratteri jolly possono essere usati per l'attestazione job_workflow_ref personalizzata di GitHub.

Nota

Il supporto flessibile delle credenziali di identità federate è attualmente disponibile per la corrispondenza con i token rilasciati da GitHub, GitLab e Terraform Cloud. Questo supporto esiste solo per le credenziali di identità federate configurate sugli oggetti applicazione attualmente. È possibile creare e gestire credenziali di identità federate flessibili solo tramite Microsoft Graph o il portale di Azure.

Struttura flessibile del linguaggio delle credenziali delle identità federate

Un'espressione di credenziali di identità federata flessibile è costituita da tre parti: la ricerca della dichiarazione, l'operatore e il comparand. Per una suddivisione di ogni parte, vedere la tabella seguente:

Nome Descrizione Esempio
Ricerca richiesta La ricerca della richiesta deve seguire il modello di claims[‘<claimName>’] claims['sub']
Operatore La parte dell'operatore deve essere solo il nome dell'operatore, separato dalla ricerca dell'attestazione e dalla comparand da un singolo spazio matches
Comparand Il comparand contiene ciò con cui si intende confrontare il claim specificato nella ricerca - deve essere racchiuso tra virgolette singole. 'repo:contoso/contoso-repo:ref:refs/heads/*'

Un esempio di espressione di credenziali di identità federata flessibile sarà simile all'oggetto JSON seguente:

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

Configurare le credenziali di identità federate tramite Microsoft Graph

Per supportare la funzionalità flessibile delle credenziali delle identità federate, la risorsa federatedIdentityCredentials viene estesa con una nuova proprietà claimsMatchingExpression. Oltre a questo, la proprietà subject è ora annullabile. Le proprietà claimsMatchingExpression e subject si escludono a vicenda, quindi non è possibile definire entrambe le proprietà all'interno di una credenziale di identità federata.

  • audiences: il gruppo di destinatari che può essere visualizzato nel token esterno. Questo campo è obbligatorio e deve essere impostato su api://AzureADTokenExchange per Microsoft Entra ID. Indica ciò che Microsoft Identity Platform deve accettare nell'attestazione aud nel token in ingresso. Questo valore rappresenta l'ID Microsoft Entra nel tuo provider di identità esterno e non ha un valore fisso tra i diversi provider di identità. Potrebbe essere necessario creare una nuova registrazione dell'applicazione nel tuo IdP per servire come pubblico di questo token.
  • issuer: L'URL del provider di identità esterno. Deve corrispondere all'attestazione dell'autorità emittente del token esterno scambiato.
  • subject: L'identificatore del carico di lavoro del software esterno presso il provider di identità esterno. Come il valore del gruppo di destinatari, non ha un formato fisso, perché ogni IdP usa il proprio , a volte un GUID, a volte un identificatore delimitato da due punti, talvolta stringhe arbitrarie. Il valore qui deve corrispondere all'attestazione sub all'interno del token presentato a Microsoft Entra ID. Se subject è definito, claimsMatchingExpression deve essere impostato su Null.
  • name: stringa univoca per identificare le credenziali. Questa proprietà è una chiave alternativa e il valore può essere usato per fare riferimento alle credenziali dell'identità federata tramite le operazioni di GET e UPSERT.
  • claimsMatchingExpression: nuovo tipo complesso contenente due proprietà, value e languageVersion. Il valore viene utilizzato per definire l'espressione e languageVersion viene utilizzato per definire la versione del linguaggio di espressione delle credenziali di identità federata flessibile (FFL) in uso. languageVersion deve essere sempre impostato su 1. Se claimsMatchingExpression è definito, subject deve essere impostato su Null.

Funzionalità del linguaggio espressivo delle credenziali di identità federata flessibile

Le credenziali di identità federate flessibili supportano attualmente l'uso di alcuni operatori tra le autorità emittenti abilitate. Le virgolette singole vengono interpretate come caratteri di escape all'interno del linguaggio di espressione flessibile delle credenziali di identità federata.

Operatore Descrizione Esempio
matches Abilita l'uso di caratteri a singolo carattere (indicati da ?) e di caratteri a multi-carattere (indicati da *) per il confronto con caratteri jolly per la dichiarazione specificata. • “claims[‘sub’] matches ‘repo:contoso/contoso-repo:ref:refs/heads/*’”
• “claims[‘sub’] matches ‘repo:contoso/contoso-repo-*:ref:refs/heads/????’”
eq Utilizzato per verificare una dichiarazione specificata • “claims[‘sub’] eq ‘repo:contoso/contoso-repo:ref:refs/heads/main’”
and Operatore booleano per la combinazione di espressioni su più attestazioni • “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 degli emittenti, dichiarazioni supportate e operatori per piattaforma

A seconda della piattaforma in uso, è necessario implementare diversi URL dell'autorità emittente, attestazioni e operatori. Usare le schede seguenti per selezionare la piattaforma scelta.

URL emittente supportati: https://token.actions.githubusercontent.com

Attestazioni e operatori supportati per ogni attestazione:

  • La richiesta sub supporta gli operatori eq e matches
  • L'attestazione job_workflow_ref supporta operatori eq e matches

Provider di Azure CLI, Azure PowerShell e Terraform

Il supporto esplicito per le credenziali delle identità federate flessibili non è ancora disponibile all'interno di Azure CLI, Azure PowerShell o dei provider Terraform. Se si tenta di configurare una credenziale di identità federata flessibile con uno di questi strumenti, viene visualizzato un errore. Inoltre, se si configura una credenziale di identità federata flessibile tramite Microsoft Graph o il portale di Azure e si tenta di leggere tale credenziale di identità federata flessibile con uno di questi strumenti, viene visualizzato un errore.

È possibile usare il metodo az rest dell'interfaccia della riga di comando di Azure per inviare richieste API REST per la creazione e la gestione flessibili delle credenziali delle identità federate.

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

Contenuto correlato