Esempio di API protetta dal framework di consenso delle identità Microsoft

Questo articolo consente, come sviluppatore, di progettare la strategia di autorizzazioni dell'applicazione per fornire privilegi minimi. Prima di procedere, vedere l'articolo Protezione API per informazioni sulle procedure consigliate per la registrazione, le autorizzazioni e l'accesso.

Esaminiamo ora come un'API protetta da Microsoft Identity Platform usa il framework di consenso delle identità Microsoft. L'API Microsoft Graph viene usata come esempio perché usa il framework di consenso di Microsoft Identity Platform più esteso.

Convenzione di denominazione per i nomi delle autorizzazioni

Il team di Microsoft Graph ha creato una convenzione di denominazione per i nomi delle autorizzazioni per semplificare la connessione dell'autorizzazione all'accesso alla risorsa abilitata dall'autorizzazione. I nomi delle autorizzazioni di Microsoft Graph rispettano un modello resource.operation.constraint semplice. Le due operazioni principali sono Read e ReadWrite (che include l'aggiornamento e l'eliminazione).

L'elemento vincolo influisce sul grado di accesso che l'app ha all'interno della directory. Microsoft Graph supporta questi vincoli:

• Tutte le autorizzazioni concesse all'app per eseguire le operazioni su tutte le risorse del tipo specificato in una directory.
• Le concessioni condivise consentono all'app di eseguire le operazioni sulle risorse condivise da altri utenti con l'utente connesso.
• AppFolder concede all'app l'autorizzazione per leggere e scrivere file in una cartella dedicata in OneDrive. Questo vincolo viene esposto solo nell'oggetto autorizzazioni Files ed è valido solo per gli account Microsoft.
• Se si specifica Nessun vincolo, l'app può eseguire solo le operazioni sulle risorse di proprietà dell'utente connesso.

Accesso e operazioni su risorse specifiche

Verranno ora esaminate alcune autorizzazioni, o ambiti, per l'oggetto utente in Microsoft Graph per vedere come le finestre di progettazione API Microsoft hanno abilitato operazioni e accesso specifici su risorse specifiche:

User.Read e User.ReadWrite esistono (anziché una singola autorizzazione come User.Access quella non esiste) in modo che le applicazioni possano seguire il principio Zero Trust dei privilegi minimi. Se lo sviluppatore non ha requisiti e codice per aggiornare il profilo dell'utente, l'app non richiede User.ReadWrite. Pertanto, un utente malintenzionato non può compromettere l'applicazione e usarla per modificare i dati.

Si noti che User.Read non concede solo all'applicazione l'accesso all'oggetto utente. Ogni autorizzazione rappresenta un intervallo specifico di operazioni. È importante che gli sviluppatori e gli amministratori leggano la descrizione dell'autorizzazione per vedere esattamente cosa abilita qualsiasi autorizzazione specifica. User.Read, oltre ad abilitare la lettura del profilo completo dell'utente corrente, consente all'applicazione di visualizzare le informazioni di base dell'oggetto Organizations in Microsoft Graph.

Si esaminerà ora un'altra autorizzazione:

Intervallo di operazioni che inizia con tutto ciò che User.ReadBasic.All User.Read fa. Inoltre, è possibile accedere al nome visualizzato, al nome e alla famiglia, all'indirizzo di posta elettronica, alla foto e alle estensioni aperte per altri utenti dell'organizzazione. L'intervallo specifico di operazioni consente alle applicazioni di avere un'interfaccia utente di selezione utenti interessante ed è un esempio di finestre di progettazione API che usano un'autorizzazione per abilitare un intervallo di operazioni specifico.

Verranno ora esaminate altre autorizzazioni per l'oggetto utente di Microsoft Graph:

Come per User.Read e User.ReadWriteUser.Read.All , e User.ReadWrite.All sono autorizzazioni distinte che consentono a un'applicazione di seguire il principio zero trust con privilegi minimi.

User.Read.All è interessante perché ogni utente dell'organizzazione ha questa funzionalità (ad esempio, aprire Outlook, andare su e giù per una catena di report). L'utente può visualizzare il profilo utente completo di ogni altro utente dell'organizzazione. Tuttavia, i progettisti dell'API Microsoft Graph hanno deciso che solo gli amministratori devono consentire a un'applicazione di eseguire la stessa operazione perché User.Read.All include la gerarchia organizzativa del tenant. Se un attore malintenzionato ha eseguito l'accesso a queste informazioni, potrebbe montare un attacco di phishing mirato in cui il messaggio di posta elettronica di phishing proviene dal manager di una persona o dal manager del manager.

User.ReadWrite.All è una potente gamma di operazioni. Un'applicazione a cui è stata concessa questa autorizzazione può aggiornare o persino eliminare ogni utente nel tenant. Come autorizzazione delegata, quando un utente si trova davanti all'app, l'app può eseguire solo le operazioni che l'utente corrente può eseguire. Gli utenti normali non possono aggiornare o eliminare altri utenti indipendentemente dalle autorizzazioni dell'app. Tuttavia, quando un amministratore tenant usa l'app, può eseguire queste operazioni. Quando si decide di concedere o negare questa autorizzazione, è necessario valutare l'app tenendo presente un utente amministratore tenant.

Autorizzazioni che richiedono il consenso amministratore

Data la potenza di User.Read.All e User.ReadWrite.All, le finestre di progettazione dell'API Microsoft Graph hanno designato queste autorizzazioni come richiesta di consenso amministratore. Aggiungiamo un Amministrazione? Colonna della tabella delle autorizzazioni da indicare quando l'autorizzazione richiede il consenso dell'amministratore:

Come illustrato nell'articolo Richiedere autorizzazioni che richiedono il consenso amministrativo, gli amministratori tenant possono ignorare i requisiti e designare qualsiasi o tutte le autorizzazioni dell'applicazione nel tenant in quanto richiedono il consenso dell'amministratore. È consigliabile progettare l'app per gestire correttamente quando non si riceve un token dalla richiesta. La mancanza di consenso è uno dei molti motivi per cui l'app potrebbe non ricevere un token.

Passaggi successivi

• Chiamare un'API da un'altra API consente di garantire Zero Trust quando si dispone di un'API che deve chiamare un'altra API e sviluppare in modo sicuro l'applicazione quando lavora per conto di un utente.
• Acquisire l'autorizzazione per accedere alle risorse consente di comprendere come garantire al meglio Zero Trust durante l'acquisizione delle autorizzazioni di accesso alle risorse per l'applicazione.
• 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 e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruolo dell'app e assegnare gruppi di sicurezza ai ruoli dell'app. Questi metodi consentono di migliorare la flessibilità e il controllo aumentando la sicurezza senza attendibilità delle applicazioni con privilegi minimi.
• Richiedere autorizzazioni che richiedono il consenso amministrativo descrive l'autorizzazione e l'esperienza di consenso quando le autorizzazioni dell'applicazione richiedono il consenso amministrativo.
• In questa guida introduttiva: Proteggere un'API Web con Microsoft Identity Platform, scaricare ed eseguire un esempio di codice che illustra come proteggere un'API Web ASP.NET.
• In questa esercitazione: Trasformare e proteggere l'API in Azure Gestione API, informazioni sulla configurazione di criteri comuni per nascondere le informazioni sullo stack di tecnologie e gli URL originali nel corpo della risposta HTTP dell'API.
• Le procedure consigliate per l'autorizzazione consentono di implementare i modelli di autorizzazione, autorizzazione e consenso ottimali per le applicazioni.