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 di gruppi di sicurezza assegnati a un utente, ruoli della directory Microsoft Entra e gruppi di distribuzione come attestazioni in un token. È 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. Le procedure consigliate per gli sviluppatori Zero Trust migliorano la flessibilità e il controllo aumentando la sicurezza delle applicazioni con privilegi minimi.

È 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. Per un elenco dei valori dell'attestazione , consultare wids.

Per aggiungere le groups e wids attestazioni ai token, selezionare Tutti i gruppi come mostrato nel seguente esempio della schermata Registrazioni app | Configurazione token | Attestazioni facoltative | Modifica attesazioni gruppo.

Eccedenze di gruppo

Quando si richiedono tutti i gruppi nel token, come illustrato nell'esempio, non è possibile fare affidamento sul token con l'attestazione groups nel token. 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'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'attestazione di eccedenza di gruppo consiste nel selezionare Gruppi assegnati all'applicazione nella schermata Modifica attestazione gruppi anziché Tutti i gruppi.

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

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

A partire dalla pubblicazione di questo articolo, l'opzione Gruppi assegnati all'applicazione non supporta 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 Registrazioni app | Ruoli app | Crea ruolo app, selezionare Utenti/Gruppi per Tipi di membri consentiti.

Dopo aver creato il ruolo dell'app nella registrazione dell'app, è possibile 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 include ruoli app definiti che consentono utenti e gruppi come membri, quando un utente o un gruppo viene assegnato all'app, uno dei ruoli dell'app definiti deve far parte dell'assegnazione dell'utente o del gruppo all'app. Se l'app include solo ruoli con privilegi elevati definiti (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. Per informazioni su come implementare la logica di autorizzazione nelle app, vedere Implementare il controllo degli accessi in base al ruolo nelle applicazioni.

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 dell'applicazione con privilegi minimi.
• Configurare le attestazioni di gruppo per le applicazioni usando l'ID Microsoft Entra mostra in che modo Microsoft Entra ID può fornire informazioni sull'appartenenza a un gruppo di un utente nei token da usare all'interno delle applicazioni.
• Le procedure consigliate per la sicurezza per le proprietà dell'applicazione descrivono 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 di Microsoft Identity Platform illustrano i concetti fondamentali dell'accesso e dell'autorizzazione per creare applicazioni più sicure e affidabili.
• Utilizzare le migliori pratiche di sviluppo per la gestione delle identità e degli accessi Zero Trust nel ciclo di sviluppo delle applicazioni per creare applicazioni sicure.