Condividi tramite

Autorizzare applicazioni, risorse e carichi di lavoro con Microsoft Entra ID

  • Articolo

In questo articolo viene descritta l'autorizzazione quando un singolo utente interagisce e indirizza un'applicazione, quando l'API (Application Programming Interfaces) agisce per un utente. Inoltre, viene illustrato il caso in cui le applicazioni o i servizi operino in modo indipendente. Si tratta del quarto di una serie di articoli sul modo in cui i fornitori di software indipendenti (ISV) possono creare e ottimizzare le applicazioni per Microsoft Entra ID. In questa serie sono disponibili altre informazioni sugli argomenti seguenti:

Autorizzazione nelle applicazioni

In questa sezione vengono illustrati gli scenari in cui un singolo utente interagisce con e indirizza un'applicazione. La sezione Autorizzazione nelle risorse (API) descrive come le API eseguono l'autorizzazione quando l'utente deve disporre dell'autorizzazione per accedere a una risorsa, ma Microsoft Entra ID non esegue l'autorizzazione finale. La sezione Autorizzazione nei carichi di lavoro illustra gli scenari in cui le applicazioni o i servizi funzionano in modo indipendente.

Le applicazioni richiedono le autorizzazioni seguenti quando devono accedere alle risorse per un utente.

  • L'applicazione deve disporre dell'autorizzazione per accedere a operazioni specifiche all'interno di risorse specifiche per l'utente corrente.
  • L'utente deve disporre dell'autorizzazione per accedere a una risorsa nelle condizioni correnti.
  • L'utente deve disporre dell'autorizzazione per accedere a una risorsa.

Il processo di autorizzazione inizia con un'applicazione che usa OAuth 2.0 per richiedere un token di accesso da Microsoft Entra ID per accedere a operazioni specifiche all'interno di una risorsa specifica per l'utente. In accesso delegato un'app funge da delegato per l'utente.

Per i developer, una risorsa può essere un'API come Microsoft Graph, Archiviazione di Azure o la propria API. Tuttavia, la maggior parte delle API ha diverse operazioni, ad esempio lettura e scrittura. Quando un'applicazione legge solo da un'API, un'app deve avere l'autorizzazione solo per le operazioni di lettura. Questo approccio protegge un'applicazione dalla compromissione e dall'uso per un accesso maggiore rispetto a quello previsto dallo sviluppatore. Lo sviluppatore segue il principio dei privilegi minimi quando l'applicazione autorizza solo per le operazioni richieste.

Per designare le operazioni specifiche in un'API specifica richiesta da un'applicazione, i developer usano il parametro di ambito di una richiesta OAuth 2.0. Il designer API pubblica gli ambiti che un'applicazione può richiedere come parte della registrazione dell'app dell'API. Ad esempio, gli ambiti del servizio Microsoft Power BI includono quanto segue.

Ambito del servizio Power BI Operazioni
https://analysis.windows.net/powerbi/api/Capacity.Read.All L'app può visualizzare tutte le capacità di Power BI Premium e Power BI Embedded a cui l'utente connesso ha accesso.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All L'app può visualizzare e modificare tutte le capacità di Power BI Premium e Power BI Embedded a cui l'utente connesso ha accesso.

Se un'applicazione legge solo le capacità, l'app richiede l'ambito https://analysis.windows.net/powerbi/api/Capacity.Read.All. Se un'applicazione modifica la capacità, l'app richiede l'ambito https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All.

L'ambito contiene l'identità dell'API e l'identità dell'operazione. Nell'ambito https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All l'API è https://analysis.windows.net/powerbi/api. L'operazione è Capacity.ReadWrite.All. Data l'ampia portata e la popolarità dell'API Microsoft Graph, i developer possono richiedere ambiti per Microsoft Graph senza il componente API dell'ambito. Ad esempio, Microsoft Graph definisce un ambito di https://graph.microsoft.com/Files.Read che le applicazioni possono richiedere con Files.Read anziché usare il nome completo dell'ambito.

Per completare la prima autorizzazione, un'applicazione deve disporre dell'autorizzazione per accedere a operazioni specifiche all'interno di risorse specifiche per l'utente corrente, Microsoft Entra ID deve prima autenticare l'utente corrente. L'accesso Single Sign-On (SSO) può soddisfare questa autenticazione oppure potrebbe richiedere un'interazione utente aggiornata.

Dopo che Microsoft Entra ID determina l'utente, verifica se l'utente ha autorizzato l'applicazione per l'ambito richiesto. Questo processo è noto come concessione del consenso. Se l'utente ha concesso il consenso, il processo di autorizzazione può continuare. Il consenso amministratore consente agli utenti amministratori di fornire il consenso per se stessi e per l'intera organizzazione. Microsoft Entra ID verifica se l'applicazione dispone del consenso amministratore per un ambito. Se concesso, il processo di autorizzazione continua.

Durante la progettazione dell'ambito, un designer API può designare gli ambiti per i quali solo un amministratore può fornire il consenso. Gli ambiti che richiedono il consenso dell'amministratore rappresentano operazioni che il designer API considera più sensibili, potenti o sufficientemente implicite che un utente non amministratore non debba avere l'autorità per concedere a un'applicazione.

Anche se i designer API hanno la prima voce in cui gli ambiti richiedono il consenso dell'amministratore, non hanno la parola finale. Quando un designer API designa che un ambito richiede il consenso dell'amministratore, l'ambito richiede sempre il consenso amministratore. Per gli ambiti che il designer API non designa come necessari del consenso dell'amministratore, l'amministratore tenant può richiedere il consenso dell’ amministratore oppure il consenso superiore basato sul rischio può determinare il requisito di consenso dell’amministratore. I developer non possono prevedere se una richiesta di token richiede il consenso amministratore. Tuttavia, questa limitazione non influisce sul codice necessario. La negazione del consenso è solo uno dei molti motivi per cui la richiesta di token viene negata. Le applicazioni devono sempre gestire correttamente la mancata ricezione di un token.

Se l'utente o l'amministratore non ha concesso il consenso, l'utente visualizza una richiesta di consenso come illustrato nell'esempio seguente.

Screenshot della richiesta di consenso dell'utente.

Le richieste di consenso dell'utente amministratore possono consentire al suddetto di selezionare Consenso per conto dell'organizzazione per concedere il consenso per tutti gli utenti nel tenant, come illustrato nell'esempio seguente.

Screenshot della richiesta di consenso dell'amministratore.

Le applicazioni controllano la tempistica delle richieste di consenso dell'utente. Microsoft Entra ID supporta il consenso statico: quando un'applicazione usa l'ambito .default, l'app richiede tutte le autorizzazioni dichiarate nella registrazione dell'app. Con il consenso statico, l'app richiede in anticipo tutte le autorizzazioni necessarie.

Il consenso statico può scoraggiare gli utenti e gli amministratori dall'approvazione della richiesta di accesso dell'app. La procedura consigliata per il processo di richiesta di consenso consiste nel richiedere in modo dinamico le autorizzazioni necessarie per la funzionalità di base nell'applicazione all'avvio dell'applicazione e richiedere più ambiti, quando necessario. Richiedere in modo incrementale più ambiti perché l'applicazione esegue operazioni che richiedono tali ambiti. Questo approccio offre all'utente una migliore comprensione di altre autorizzazioni correlate alla tempistica delle funzionalità. Per ogni token di accesso all'API, Microsoft Entra ID include tutti gli ambiti precedentemente concessi a un'applicazione e non solo gli ambiti nella richiesta.

Ad esempio, un'applicazione può richiedere https://graph.microsoft.com/user.read per eseguire l’accesso dell'utente e accedere al profilo dell'utente all'avvio dell'applicazione. Successivamente, un utente seleziona Salva in OneDrive e l'applicazione richiede https://graph.microsoft.com/files.readwrite per scrivere un file nel OneDrive dell'utente. Poiché l'utente vede perché un'app chiede di scrivere in OneDrive, l'utente concede l'autorizzazione e l'app salva un file in OneDrive dell'utente. L'utente chiude quindi l'app. Al successivo avvio dell'app, richiede https://graph.microsoft.com/user.read. Microsoft Entra ID restituisce un token di accesso con ambiti https://graph.microsoft.com/user.read e https://graph.microsoft.com/files.readwrite. Una richiesta di token per l'ambito https://graph.microsoft.com/files.readwrite non richiede il consenso in quanto l'utente lo ha concesso. La memorizzazione nella cache dei token in Microsoft Authentication Libraries (MSAL) gestisce automaticamente i token di memorizzazione nella cache in base alle autorizzazioni concesse. In questo esempio, dopo il riavvio dell'app, le chiamate MSAL per acquisire un token con l'ambito https://graph.microsoft.com/files.readwrite restituiscono il token memorizzato nella cache dalla richiesta iniziale dell'app per l'ambito https://graph.microsoft.com/user.read. Non è necessaria un'altra chiamata a Microsoft Entra ID.

Il consenso dinamico e incrementale non richiede autorizzazioni dichiarate durante la registrazione dell'applicazione. È tuttavia consigliabile che le applicazioni dichiarino tutte le autorizzazioni che un'applicazione potrebbe richiedere in una registrazione dell'app per supportare il consenso statico. Gli amministratori possono concedere il consenso amministratore nell'interfaccia di amministrazione di Microsoft Entra, con Microsoft Graph PowerShell o l'API Microsoft Graph.

Per concedere il consenso amministratore per un'applicazione, l'interfaccia di amministrazione di Microsoft Entra usa il consenso statico richiedendo il consenso con l'ambito .default di un'app. Gli amministratori non possono concedere il consenso amministratore nell'interfaccia di amministrazione di Microsoft Entra alle app che richiedono l'autorizzazione se i developer non li dichiarano nella registrazione dell'app.

I clienti di Microsoft Entra ID possono usare i criteri di Accesso condizionale per proteggere le risorse (API) e le applicazioni basate su browser. Per impostazione predefinita, gli amministratori non possono applicare criteri di Accesso condizionale alle autenticazioni di app native. Gli amministratori tenant possono definire come destinazione tutte le risorse (in precedenza "Tutte le app cloud") o usare attributi di sicurezza personalizzati per definire come destinazione le app native con i criteri di accesso condizionale. Anche se diversamente mirata, l'applicazione dei criteri non include alcune app che accedono a Microsoft Graph o Azure AD Graph.

Le applicazioni in genere non richiedono codice speciale per l'Accesso condizionale, a meno che non si applichino gli scenari seguenti.

  • App che eseguono il flusso on-behalf-of
  • App che accedono a più servizi o risorse
  • App a pagina singola che usano MSAL.js
  • App Web che chiamano una risorsa

Se l'app implementa uno di questi scenari, vedere Linee guida per i developer per l'Accesso condizionale di Microsoft Entra.

I tenant di Microsoft Entra ID gratuito non possono usare l'Accesso condizionale (vedere i requisiti di licenza). Il tenant di produzione dell'azienda potrebbe avere le licenze necessarie. Valutare queste condizioni prima di usare il tenant di produzione per i test. Sono disponibili indicazioni per creare un tenant di test.

Per impostazione predefinita, i criteri di Accesso condizionale si applicano alle applicazioni e alle risorse a cui accede un'app a livello di app. Gli amministratori IT possono applicare criteri a livello di app a qualsiasi app senza la partecipazione dei developer. Alcune applicazioni e scenari richiedono una maggiore granularità. Ad esempio, un'app finanziaria può richiedere l'autenticazione a più fattori per un uso tipico. Tuttavia, una transazione su un importo designato può richiedere un dispositivo gestito. I developer possono consentire agli amministratori IT di assegnare criteri di Accesso condizionale superiore a diverse aree di un'applicazione implementando il contesto di autenticazione dell'Accesso condizionale. La guida per i developer al contesto di autenticazione dell'Accesso condizionale è un buon riferimento per queste funzionalità.

Per impostazione predefinita, Microsoft Entra ID rilascia i token di accesso validi per un periodo di tempo impostato. Le applicazioni non devono mai presupporre la durata. Devono usare il parametro expires_in restituito da Microsoft Entra ID con il token di accesso. MSAL gestisce automaticamente questo scenario. Per la durata del token di accesso, l'utente ha l'autorizzazione per accedere alla risorsa in base alle condizioni al momento dell'autorizzazione.

Il ritardo tra quando le condizioni cambiano e quando si verifica l'imposizione delle modifiche dei criteri può riguardare amministratori e utenti. Ad esempio, quando un utente perde un dispositivo, l'amministratore IT può revocare le sessioni dell'utente. Tuttavia, un'app nel dispositivo perso può continuare ad accedere a Microsoft Graph per l'utente fino alla scadenza del token. La valutazione dell'accesso continuo (CAE)Microsoft può impedire l'accesso dopo la revoca delle sessioni utente per le applicazioni che adottano la CAE. Se l'applicazione chiama Microsoft Graph almeno una volta all'ora, è possibile adottare CAE. Come usare le API abilitate per la valutazione continua dell'accesso nelle applicazioni fornisce informazioni dettagliate sull’implementazione.

Se non è possibile eseguire la compilazione in MSAL, l'app deve usare OAuth 2.0 per richiedere token di accesso da Microsoft Entra ID. Il flusso del codice di autorizzazione di Microsoft Identity Platform e OAuth 2.0 fornisce informazioni dettagliate sull'implementazione per i flussi supportati da Microsoft Entra ID.

Se si creano app per dispositivi mobili, vedere Supportare l'accesso Single Sign-On e i criteri di protezione delle app nelle app per dispositivi mobili. Informazioni su come supportare l'acquisizione dei token, la gestione di applicazioni mobili (MAM) Intune e i criteri di protezione delle app.

Autorizzazione nelle risorse (API)

La sezione Autorizzazione nelle applicazioni ha introdotto tre autorizzazioni necessarie quando le applicazioni devono accedere alle risorse per un utente, tuttavia, sono illustrate solo le prime due. L'utente deve disporre dell'autorizzazione per accedere a una risorsa, ma Microsoft Entra ID non esegue l'autorizzazione finale. La risorsa (API) esegue l'autorizzazione.

Le API devono applicare due autorizzazioni quando agiscono per un utente:

  • Le API devono autorizzare un'app a chiamare l'API. Verificare che l'attestazione (ambito) scp del token di accesso contenga l'ambito richiesto.
  • Le API devono autorizzare l'utente ad accedere alla risorsa specifica. Le attestazioni oid (ID oggetto) e sub (soggetto) nel token rappresentano l'identità utente.

È consigliabile usare le attestazioni oid e sub per l'autorizzazione.

Microsoft Entra ID implementa un'attestazione sub pairwise, pertanto l'attestazione sub è un identificatore utente univoco per l'app richiedente. Lo stesso utente che usa un'app diversa ha un'attestazione sub differente. L'attestazione oid è costante per l'utente per tutte le app.

Le applicazioni forniscono il token di accesso necessario alle API protette da Microsoft Entra ID nell'intestazione di autorizzazione della richiesta http come token di connessione. Le API devono convalidare completamente il token ricevuto perché il token non proviene direttamente da Microsoft Entra ID. Considerare l'app chiamante come non attendibile fino alla convalida del token. Gli articoli di riferimento sui token di accesso e sulla convalida delle attestazioni forniscono informazioni dettagliate sulla convalida dei token di accesso all'ID di Microsoft Entra.

Microsoft Entra ID pubblica le chiavi pubbliche usate dalle API per convalidare la firma del token. Queste chiavi vengono rollover periodicamente e ogni volta che la situazione richiede il rollover della chiave pubblica. L'applicazione non deve mai presupporre una pianificazione impostata per il rollover della chiave pubblica. Il rollover della chiave di firma in Microsoft Identity Platform spiega come gestire correttamente il rollover della chiave pubblica.

È consigliabile usare una libreria ben gestita per eseguire la convalida dei token. Se si sta creando un'app Web o un'API in ASP.NET o ASP.NET Core, usare Microsoft.Identity.Web per gestire la convalida dei token. L'articolo sulle procedure relative all'API Web protetta illustra come usare Microsoft.Identity.Web per proteggere un'API.

Le API a volte devono chiamare altre API. Quando un'app funziona per l'utente, l'API riceve un token di accesso delegato che include l'identità dell'utente corrente. È importante che l'API consideri attendibile solo un token convalidato da Microsoft Entra ID per determinare l'identità dell'utente corrente. Questo approccio impedisce la compromissione dell'applicazione in modo che gli utenti impersonino altri utenti e accedano a risorse per un utente differente. Per questa stessa protezione quando un'API chiama un'altra API, usare il flusso Per conto di OAuth per acquisire un token di accesso per chiamare un'API per l'utente per cui è stata chiamata l'API. Creare un'API Web che chiama le API Web fornisce la procedura per un'API per chiamare altre API per l'utente dell'app corrente.

Oltre all'accesso delegato, le API potrebbero dover supportare le applicazioni e agire in modo indipendente senza utenti correnti. Microsoft Entra ID fa riferimento a queste applicazioni come carichi di lavoro. Per applicare l'autorizzazione del carico di lavoro, le API non usano l'attestazione scp (ambito). Le API usano invece l'attestazione roles per verificare che il carico di lavoro disponga del consenso necessario. Le API sono responsabili dell'applicazione dell'autorizzazione del carico di lavoro per accedere alla risorsa.

Autorizzazione nei carichi di lavoro

I carichi di lavoro sono applicazioni che funzionano in modo indipendente e non hanno un utente corrente. Analogamente all'accesso delegato descritto nella sezione Autorizzazione nelle applicazioni, l'accesso solo app richiede varie autorizzazioni:

  • L'applicazione deve disporre dell'autorizzazione per accedere a operazioni specifiche all'interno di risorse specifiche.
  • L'applicazione deve disporre dell'autorizzazione per accedere alla risorsa nelle condizioni correnti.
  • L'applicazione deve disporre dell'autorizzazione per accedere alla risorsa.

Il processo inizia con un carico di lavoro che richiede un token di accesso con l'ambito .default (ad esempio https://graph.microsoft.com/.default). A differenza dell'accesso delegato (le applicazioni possono richiedere ambiti in modo dinamico e incrementale), i carichi di lavoro devono sempre usare il consenso statico e l'ambito .default.

I designer API creano autorizzazioni per le app per le loro API aggiungendo ruoli alla registrazione dell'app dell'API. Questi ruoli hanno un tipo di membro consentito di applicazioni, che consente l'assegnazione di ruoli ai carichi di lavoro. Assegnare ruoli ai carichi di lavoro nell'interfaccia di amministrazione di Microsoft Entra o con Microsoft Graph. Nell'interfaccia di amministrazione di Microsoft Entra il consenso amministratore per i ruoli assegnati è necessario prima che sia possibile eseguire il carico di lavoro.

Per impostazione predefinita, un'autorizzazione dell'app autorizza i carichi di lavoro ad accedere a tutte le istanze di una risorsa. Ad esempio,https://graph.microsoft.com/user.read.all autorizza un carico di lavoro ad accedere al profilo utente completo di ogni utente nel tenant. Gli amministratori IT sono spesso riluttanti a concedere queste autorizzazioni generali.

Per i carichi di lavoro che accedono a Microsoft Graph, usare questi metodi per limitare l'autorizzazione dell'applicazione:

A differenza delle applicazioni con gli utenti, i carichi di lavoro si autenticano con Microsoft Entra ID.

Per i carichi di lavoro eseguiti in Microsoft Azure, il metodo migliore per un carico di lavoro per eseguire l’autenticazione è rappresentato dalle identità gestite per le risorse di Azure. La funzionalità identità gestite rimuove la necessità di gestire le credenziali per il carico di lavoro. Nessuna credenziale accessibile. Microsoft Entra ID gestisce completamente le credenziali. Senza credenziali da gestire, nessuna credenziale è a rischio di compromissione.

Con una maggiore sicurezza, anche le identità gestite aumentano la resilienza. Le identità gestite usano token di accesso e informazioni di lunga durata da Microsoft Entra ID per ottenere nuovi token prima della scadenza dei token. Le identità gestite usano endpoint a livello di area geografica (o regione), che contribuiscono a evitare errori al di fuori dell’area, consolidando le dipendenze dei servizi. Gli endpoint regionali aiutano a mantenere il traffico in una determinata area geografica. Ad esempio, se la risorsa di Azure si trova in WestUS2, tutto il traffico rimane in WestUS2.

Se il carico di lavoro non è in esecuzione in Microsoft Azure, il carico di lavoro deve eseguire l'autenticazione con il flusso di credenziali client OAuth 2.0.

Microsoft Entra ID supporta questi tipi di credenziali client:

  • Certificato. I carichi di lavoro dimostrano che hanno il possesso di una chiave privata firmando un'asserzione con la chiave privata. La chiave privata non viene trasmessa a Microsoft Entra ID. Viene inviata solo l'asserzione. È consigliabile usare certificati anziché segreti client perché sono più sicuri e spesso gestiti meglio.
  • Credenziali federate. La federazione dell'identità del carico di lavoro consente ai carichi di lavoro che non sono in esecuzione in Microsoft Azure di usare un'identità di un altro provider di identità, GitHub Actions o un cluster Kubernetes. I carichi di lavoro richiedono token nella stessa modalità sia per le credenziali federate che per quelle del certificato. La differenza è che l'asserzione, un token Web JSON firmato, proviene dal provider di identità federativo.
  • Segreto client. A volte chiamata password dell'applicazione, un segreto client è un valore stringa che il carico di lavoro può usare per identificarsi. Il valore di testo del segreto viene inviato dal carico di lavoro a Microsoft Entra ID in una richiesta POST per un token. I segreti client sono meno sicuri dei certificati o della federazione dell'identità del carico di lavoro. Se il carico di lavoro usa segreti, seguire queste procedure consigliate per la gestione dei segreti.

Oltre a Microsoft Entra ID, la famiglia di prodotti Microsoft Entra include Microsoft Entra Workload ID. Microsoft Entra Workload ID include le funzionalità Premium seguenti per migliorare la sicurezza del carico di lavoro.

  • L’Accesso condizionale supporta criteri basati sulla posizione o sui rischi per le identità del carico di lavoro.
  • Microsoft Entra ID Protection fornisce report su credenziali compromesse, accessi anomali e modifiche sospette agli account.
  • Le revisioni degli accessi consentono di delegare le revisioni alle persone giuste, in base ai ruoli con privilegi più importanti.
  • Le raccomandazioni sull'integrità delle app suggeriscono modi per risolvere i gap di protezione delle identità nel portfolio di applicazioni e migliorare la sicurezza dei tenant e la postura di resilienza.

I carichi di lavoro possono supportare la Valutazione continua dell'accesso (CAE) se chiamano Microsoft Graph almeno una volta all'ora. Per supportare CAE, il carico di lavoro deve essere un'applicazione a tenant singolo e l'app registrata nel tenant in cui accede a Microsoft Graph. Se il carico di lavoro soddisfa questi requisiti, vedere questo esempio per i passaggi di implementazione.

Passaggi successivi