Configurare attestazioni di gruppo e ruoli applicativi nei token

Questo articolo illustra come configurare le app con definizioni di ruolo dell'app e assegnare gruppi di sicurezza ai ruoli dell'app in modo da migliorare la flessibilità e il controllo aumentando al contempo la sicurezza delle applicazioni con privilegi minimi.

Microsoft Entra ID supporta l'invio, come attestazioni in un token, dei gruppi di sicurezza assegnati a un utente, dei ruoli della directory Microsoft Entra e dei gruppi di distribuzione. È possibile usare questo approccio per gestire l'autorizzazione nelle app. Tuttavia, Microsoft Entra ID limita il supporto ai gruppi in un token in base alle dimensioni del token. Quando l'utente è membro di troppi gruppi, nel token non sono presenti gruppi.

In questo articolo viene illustrato un approccio alternativo per ottenere informazioni utente nei token usando il supporto del gruppo Microsoft Entra. È invece possibile configurare le app con definizioni di ruolo dell'app e assegnare gruppi ai ruoli dell'app. Questa procedura consigliata Zero Trust per sviluppatori migliora la flessibilità e il controllo, aumentando al contempo la sicurezza delle applicazioni con il principio del minimo privilegio.

È possibile configurare le attestazioni di gruppo nei token che è possibile usare all'interno delle applicazioni per l'autorizzazione. Tenere presente che le informazioni sul gruppo nel token sono correnti solo quando si riceve il token. Le attestazioni di gruppo supportano due modelli principali:

• Gruppi identificati dall'attributo OID (Microsoft Entra Object Identifier).
• Gruppi identificati dall'attributo sAMAccountName o GroupSID per gruppi e utenti sincronizzati con Active Directory.

L'appartenenza al gruppo può guidare le decisioni di autorizzazione. Ad esempio, l'esempio seguente mostra alcune attestazioni in un token. È possibile aggiungere attestazioni e ruoli di gruppo a ID o token di accesso.

"aud": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

La matrice di attestazioni groups comprende gli ID dei gruppi a cui l'utente è membro. La matrice wids include gli ID dei ruoli di Microsoft Entra assegnati all'utente. In questo caso, cf1c38e5-3621-4004-a7cb-879624dced7c mostra che i ruoli assegnati di questo utente includono Application Developer e membro standard come indicato 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0.

L'app può prendere decisioni di autorizzazione in base alla presenza o all'assenza di queste attestazioni e ai relativi valori. Consulta i ruoli predefiniti di Microsoft Entra per un elenco di valori per la dichiarazione wids.

Per aggiungere le attestazioni di groups e wids ai token, selezionare Tutti i gruppi come illustrato nell'esempio seguente della schermata Registrazioni app | Configurazione token | Attestazioni facoltative | Schermata Modifica attestazioni gruppi.

Eccedenze di gruppo

Quando si richiedono tutti i gruppi nel token, come illustrato nell'esempio precedente, non è possibile fare affidamento sul token contenente la dichiarazione groups. Esistono limiti di dimensioni per i token e per le attestazioni groups in modo che non diventino troppo grandi. Quando l'utente è membro di troppi gruppi, l'app deve ottenere l'appartenenza al gruppo dell'utente da Microsoft Graph. I limiti per i gruppi in una richiesta groups sono:

• 200 gruppi per JSON Web token (JWT).
• 150 gruppi per i token SAML (Security Assertion Markup Language).
• Sei gruppi quando si utilizza il flusso implicito (ad esempio, utilizzando ASP.NET Core che ottiene i token ID tramite la parte implicita di un flusso ibrido).
  • Il flusso implicito non è più consigliato per le app Web a pagina singola.
  • Il flusso implicito può essere usato nelle app Web solo per il token ID, mai il token di accesso, in un flusso ibrido OAuth2.

Se si usa OpenID Connect o OAuth2, è possibile avere fino a 200 gruppi nel token. Se si usa SAML, è possibile avere solo 150 gruppi perché i token SAML sono più grandi dei token OAuth2 e OpenID Connect. Se si usa il flusso implicito, il limite è sei perché tali risposte vengono visualizzate nell'URL. In tutti questi casi, invece di avere un'attestazione groups, viene visualizzata un'indicazione (nota come eccedenza di gruppo) che indica che l'utente è un membro di troppi gruppi da inserire nel token.

L'attestazione groups deve essere associata a src1. In teoria, dovresti cercare l'attestazione _claim_sources e poi troveresti il membro src1. Da qui è possibile trovare la query Graph che si userà per ottenere l'appartenenza al gruppo. Tuttavia, c'è un problema con ciò che viene visualizzato nella Graph query di esempio. Si collega ad Azure AD Graph (che Microsoft sta deprecando), quindi non usarlo.

L'indicazione implicita dell'eccedenza del flusso viene eseguita con una dichiarazione hasgroups anziché con una dichiarazione groups.

Per garantire un'autorizzazione appropriata usando l'appartenenza al gruppo, fai sì che l'app verifichi la presenza dell'attestazione groups. Se presente, usare tale attestazione per determinare l'appartenenza al gruppo dell'utente. Se non è presente alcuna dichiarazione groups, verificare l'esistenza di una dichiarazione hasgroups o di una dichiarazione _claim_names con un membro groups dell'array. Se una di queste attestazioni è presente, l'utente è membro di troppi gruppi per il token. In questo caso, l'app deve usare Microsoft Graph per determinare l'appartenenza al gruppo per l'utente. Vedere Elencare le appartenenze di un utente (diretto e transitivo) per trovare tutti i gruppi, diretti e transitivi, di cui l'utente è membro.

Se l'applicazione richiede informazioni sull'appartenenza ai gruppi in tempo reale, usare Microsoft Graph per determinare l'appartenenza ai gruppi. Tenere presente che le informazioni nel token ricevuto sono aggiornate solo al momento dell'acquisizione del token.

Vedere l'esempio seguente della schermata Registrazione appconfigurazione tokendi Attestazioni facoltativeSchermata Modifica attestazioni gruppi. Un modo per evitare di raggiungere un reclamo di eccedenza di gruppo è selezionare Gruppi assegnati all'applicazione nella schermata Modifica reclamo gruppi invece di Tutti i gruppi.

Quando si seleziona Gruppi assegnati all'applicazione, un gruppo viene incluso nella rivendicazione groups se sono soddisfatte le seguenti condizioni:

• il gruppo viene assegnato all'applicazione aziendale
• l'utente è un membro diretto del gruppo

A partire dalla pubblicazione di questo articolo, i gruppi assegnati all'opzione applicativa non supportano l'appartenenza indiretta. L'assegnazione di gruppo richiede almeno una licenza a livello P1. Un tenant gratuito non può assegnare gruppi a un'applicazione.

Gruppi e ruoli dell'app

Un altro modo per evitare il problema di eccedenza del gruppo consiste nel definire ruoli per l'app che includono utenti e gruppi come tipi di membri. Come illustrato nel seguente esempio della schermata di registrazione app Ruoli app | | , schermata Crea ruolo app, selezionare Utenti/Gruppi per Tipi di membri consentiti .

Dopo aver creato il ruolo dell'app nella registrazionedell'app, i professionisti IT possono assegnare utenti e gruppi al ruolo. L'app riceve una dichiarazione roles nel suo token (token ID per l'app, token di accesso per le API) con tutti i ruoli assegnati all'utente collegato, come mostrato nell'esempio di token seguente.

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

Ricordati di gestire le seguenti condizioni per l'applicazione:

• assenza del reclamo roles
• l'utente non ha alcuna assegnazione di ruolo
• più valori nella dichiarazione roles quando l'utente ha più di un'assegnazione di ruolo

Quando si creano ruoli dell'app che consentono utenti e gruppi come membri, definire sempre un ruolo utente di base senza ruoli di autorizzazione elevati. Quando una configurazione dell'app aziendale richiede l'assegnazione, solo gli utenti con assegnazione diretta a un'applicazione o l'appartenenza a un gruppo assegnato all'app possono usare l'app.

Se l'app ha definito dei ruoli che permettono l'inclusione di utenti e gruppi come membri, quando un utente o un gruppo viene assegnato all'app, uno dei ruoli definiti deve essere parte dell'assegnazione dell'utente o del gruppo all'app. Se l'app ha definito solo ruoli elevati (ad esempio admin) per l'app, a tutti gli utenti e i gruppi verrà assegnato il ruolo di amministratore. Quando si definisce un ruolo di base ,ad esempio user), agli utenti e ai gruppi assegnati all'app può essere assegnato il ruolo utente di base.

Oltre ad evitare le rivendicazioni di eccedenza di gruppo, un altro vantaggio dell'uso dei ruoli è che non è necessario effettuare il mapping tra l'ID di un gruppo o il suo nome e il loro significato nell'applicazione. Ad esempio, il codice può cercare l'attestazione del ruolo di amministratore invece di scorrere i gruppi nelle attestazioni groups e decidere quali ID di gruppo devono essere consentiti alla funzionalità di amministrazione.

Verificare e usare i ruoli nel codice

Quando si definiscono i ruoli per l'applicazione, è tua responsabilità implementare la logica di autorizzazione per tali ruoli. Vedere Implementare il controllo degli accessi in base al ruolo nelle applicazioni per informazioni su come implementare la logica di autorizzazione nelle app.

Passaggi successivi

• Personalizzare i token descrive le informazioni che è possibile ricevere nei token di Microsoft Entra. Spiega come personalizzare i token per migliorare la flessibilità e il controllo, aumentando al contempo la sicurezza zero trust delle applicazioni con privilegi minimi.
• Configurare le attestazioni di gruppo per le applicazioni usando Microsoft Entra ID illustra come Microsoft Entra ID può fornire informazioni sull'appartenenza a un gruppo di un utente nei token da usare all'interno delle applicazioni.
• Procedure consigliate per la sicurezza per le proprietà dell'applicazione descrive l'URI di reindirizzamento, i token di accesso (usati per i flussi impliciti), i certificati e i segreti, l'URI ID applicazione e la proprietà dell'applicazione.
• Gli ambiti, le autorizzazioni e il consenso della piattaforma di identità Microsoft & spiega i concetti fondamentali di accesso e autorizzazione per aiutarti a creare applicazioni più sicure e affidabili.
• Utilizzare migliori pratiche di sviluppo per la gestione delle identità e degli accessi Zero Trust nel ciclo di vita dello sviluppo delle applicazioni per creare applicazioni sicure.