Configurare attestazioni di gruppo e ruoli dell'app 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 guidare l'autorizzazione nelle app. Tuttavia, microsoft Entra ID supporta il gruppo 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 per gli sviluppatori Zero Trust migliora la flessibilità e il controllo aumentando al contempo 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 i gruppi e gli 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": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"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": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

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

L'app può prendere decisioni di autorizzazione in base alla presenza o all'assenza di queste attestazioni e ai relativi valori. Per un elenco di valori per l'attestazionewids, vedere Ruoli predefiniti di Microsoft Entra.

Per aggiungere le groups attestazioni e wids ai token, selezionare Tutti i gruppi come illustrato nell'esempio seguente della schermata di attestazione Facoltativa attestazioni | Edit groups della configurazione | Registrazioni app | Token.

Eccedenze di gruppo

Quando si richiedono tutti i gruppi nel token, come illustrato nell'esempio precedente, non è possibile fare affidamento sul token con l'attestazione groups nel token. Esistono limiti di dimensioni per i token e per groups le attestazioni 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 un'attestazione groups sono:

• 200 gruppi per token Web JSON (JWT).
• 150 gruppi per i token SAML (Security Assertion Markup Language).
• Sei gruppi quando si usa il flusso implicito, ad esempio usando ASP.NET core che ottiene i token ID tramite la parte implicita del flusso 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 Connessione 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 di OAuth2 e OpenID Connessione token. 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 per adattarsi al token.

Nell'esempio di token seguente, per una connessione OpenID o OAuth2, un token Web JSON (JWT), non esiste un'attestazione groups se l'utente è membro di troppi gruppi. Esiste invece un'attestazione _claim_names che contiene un groups membro della matrice.

Nell'esempio di token precedente si noterà che l'attestazione groups deve essere mappata a src1. In teoria, cercare l'attestazione _claim_sources e quindi trovare il src1 membro. Da qui è possibile trovare la query Graph che si userà per ottenere l'appartenenza al gruppo. Tuttavia, si è verificato un problema con ciò che viene visualizzato nella query graph di esempio. Passa ad Azure AD Graph (che Microsoft sta deprecato), quindi non usarlo.

L'indicazione implicita dell'eccedenza del flusso viene eseguita con un'attestazione hasgroups anziché con l'attestazione groups .

Per garantire un'autorizzazione appropriata usando l'appartenenza al gruppo, chiedere all'app di verificare la presenza dell'attestazione groups . Se presente, usare tale attestazione per determinare l'appartenenza al gruppo dell'utente. Se non esiste alcuna groups attestazione, verificare l'esistenza di un'attestazione hasgroups o di un'attestazione _claim_names con un groups membro della matrice. 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 di configurazione | Registrazioni app | Token Optional claims Edit groups claim (Modifica attestazioni facoltative). | 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 i ruoli dell'app che consentono a utenti e gruppi come tipi di membri. Come illustrato nell'esempio seguente della schermata Registrazioni app | App roles | Create app role (Crea ruolo app), selezionare Utenti/gruppi per Tipi di membri consentiti.

Dopo aver creato il ruolo dell'app nella registrazione dell'app, i professionisti IT possono assegnare utenti e gruppi al ruolo. L'app ottiene un'attestazione roles nel token (token ID per l'app, token di accesso per le API) con tutti i ruoli assegnati dell'utente connesso, come illustrato nell'esempio di token seguente.

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

Ricordarsi di gestire le condizioni seguenti per l'applicazione:

• assenza di roles reclamo
• l'utente non ha alcuna assegnazione di ruolo
• più valori nell'attestazione 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 ruoli app 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 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), gli utenti e i gruppi assegnati all'app possono essere assegnati al ruolo utente di base.

Oltre a evitare attestazioni di eccedenza di gruppo, un altro vantaggio dell'uso dei ruoli non è necessario eseguire il mapping tra un ID gruppo o un nome e ciò che significa nell'applicazione. Ad esempio, il codice può cercare l'attestazione del ruolo di amministratore anziché scorrere i gruppi nelle groups attestazioni 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 dell'app per l'app, è responsabilità dell'utente 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 senza attendibilità delle applicazioni 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.
• Usare le procedure consigliate per lo sviluppo di identità Zero Trust e di gestione degli accessi nel ciclo di vita di sviluppo delle applicazioni per creare applicazioni sicure.