Informazioni sull'accesso solo alle applicazioni
Quando un'applicazione accede direttamente a una risorsa, ad esempio Microsoft Graph, l'accesso non è limitato ai file o alle operazioni disponibili per un singolo utente. L'app chiama le API direttamente usando la propria identità e un utente o un'app con diritti di amministratore deve autorizzarla ad accedere alle risorse. Questo scenario è l'accesso solo all'applicazione.
Quando è consigliabile usare l'accesso solo all'applicazione?
Nella maggior parte dei casi, l'accesso solo all'applicazione è più ampio e più potente rispetto all'accesso delegato, quindi è consigliabile usare solo l'accesso solo app, se necessario. In genere è la scelta giusta se:
- L'applicazione deve essere eseguita in modo automatizzato, senza input dell'utente. Ad esempio, uno script giornaliero che controlla i messaggi di posta elettronica da determinati contatti e invia risposte automatiche.
- L'applicazione deve accedere alle risorse appartenenti a più utenti diversi. Ad esempio, un'app di prevenzione della perdita dei dati o di backup potrebbe dover recuperare i messaggi da molti canali di chat diversi, ognuno con partecipanti diversi.
- Si è tentati di archiviare le credenziali in locale e consentire all'app di accedere "come" l'utente o l'amministratore.
Al contrario, è consigliabile non usare mai l'accesso solo all'applicazione, in cui un utente normalmente accede per gestire le proprie risorse. Questi tipi di scenari devono usare l'accesso delegato per avere privilegi minimi.
Autorizzazione di un'app per effettuare chiamate solo applicazione
Per effettuare chiamate solo app, è necessario assegnare all'app client i ruoli dell'app appropriati. I ruoli dell'app vengono definiti anche autorizzazioni di sola applicazione. Sono ruoli dell'app perché concedono l'accesso solo nel contesto dell'app per le risorse che definisce il ruolo.
Ad esempio, per leggere un elenco di tutti i team creati in un'organizzazione, è necessario assegnare l'applicazione al ruolo dell'app Microsoft Graph Team.ReadBasic.All . Questo ruolo dell'app concede la possibilità di leggere questi dati quando Microsoft Graph è l'app per le risorse. Questa assegnazione non assegna l'applicazione client a un ruolo di Teams che potrebbe consentire di visualizzare questi dati tramite altri servizi.
Gli sviluppatori devono configurare tutte le autorizzazioni necessarie solo app, dette anche ruoli dell'app nella registrazione dell'applicazione. È possibile configurare le autorizzazioni di sola app richieste dell'app tramite il portale di Azure o Microsoft Graph. L'accesso solo app non supporta il consenso dinamico, quindi non è possibile richiedere singole autorizzazioni o set di autorizzazioni in fase di esecuzione.
Dopo aver configurato tutte le autorizzazioni necessarie per l'app, deve ottenere il consenso dell'amministratore per accedere alle risorse. Ad esempio, solo gli utenti con il ruolo di amministratore globale possono concedere autorizzazioni solo app (ruoli dell'app) per l'API Microsoft Graph. Gli utenti con altri ruoli di amministratore, ad esempio l'amministratore dell'applicazione e l'amministratore delle app cloud, possono concedere autorizzazioni solo app per altre risorse.
Amministrazione gli utenti possono concedere autorizzazioni solo app usando il portale di Azure o creando concessioni a livello di codice tramite l'API Microsoft Graph. È anche possibile richiedere il consenso interattivo dall'interno dell'app, ma questa opzione non è preferibile perché l'accesso solo app non richiede un utente.
Gli utenti consumer con account Microsoft, ad esempio Outlook.com o gli account Xbox Live, non possono mai autorizzare l'accesso solo all'applicazione.
Segui sempre il principio dei privilegi minimi: non devi mai richiedere ruoli dell'app non necessari per l'app. Questo principio consente di limitare il rischio di sicurezza se l'app è compromessa e rende più semplice per gli amministratori concedere l'accesso all'app. Ad esempio, se l'app deve identificare gli utenti senza leggere le informazioni dettagliate sul profilo, è necessario richiedere il ruolo dell'app Microsoft Graph User.ReadBasic.All più limitato anziché User.Read.All.
Progettazione e pubblicazione di ruoli dell'app per un servizio risorse
Se si sta creando un servizio in Microsoft Entra ID che espone LE API per le chiamate di altri client, è possibile supportare l'accesso automatizzato con i ruoli dell'app (autorizzazioni solo app). È possibile definire i ruoli dell'app per l'applicazione nella sezione Ruoli app della registrazione dell'app nell'interfaccia di amministrazione di Microsoft Entra. Per altre informazioni su come creare ruoli dell'app, vedere Dichiarare i ruoli per un'applicazione.
Quando si espongono ruoli dell'app per altri utenti da usare, fornire descrizioni chiare dello scenario all'amministratore che li assegnerà. I ruoli dell'app devono in genere essere il più stretti possibile e supportano scenari funzionali specifici, poiché l'accesso solo app non è vincolato dai diritti utente. Evitare di esporre un singolo ruolo che concede l'accesso completo o completo readread/write a tutte le API e alle risorse contenute nel servizio.
Nota
I ruoli dell'app (autorizzazioni solo app) possono anche essere configurati per supportare l'assegnazione a utenti e gruppi. Assicurarsi di configurare correttamente i ruoli dell'app per lo scenario di accesso previsto. Se si prevede che i ruoli dell'app dell'API vengano usati per l'accesso solo app, selezionare le applicazioni come unici tipi di membri consentiti durante la creazione dei ruoli dell'app.
Come funziona l'accesso solo all'applicazione?
La cosa più importante da ricordare è che l'app chiamante agisce per proprio conto e come propria identità. Nessuna interazione dell'utente. Se l'app è stata assegnata a un determinato ruolo dell'app per una risorsa, l'app ha accesso completamente senza vincoli a tutte le risorse e alle operazioni regolate da tale ruolo dell'app.
Dopo che un'app è stata assegnata a uno o più ruoli dell'app (autorizzazioni solo app), può richiedere un token solo app da Microsoft Entra ID usando il flusso di credenziali client o qualsiasi altro flusso di autenticazione supportato. I ruoli assegnati vengono aggiunti all'attestazione roles del token di accesso dell'app.
In alcuni scenari, l'identità dell'applicazione può determinare se l'accesso viene concesso, in modo analogo ai diritti utente in una chiamata delegata. Ad esempio, il Application.ReadWrite.OwnedBy ruolo app concede a un'app la possibilità di gestire le entità servizio di proprietà dell'app stessa.
Esempio di accesso solo applicazione - Notifica tramite posta elettronica automatizzata tramite Microsoft Graph
L'esempio seguente illustra uno scenario di automazione realistico.
Alice vuole inviare una notifica tramite posta elettronica a un team ogni volta che la cartella di report della divisione che risiede in una condivisione file di Windows registra un nuovo documento. Alice crea un'attività pianificata che esegue uno script di PowerShell per esaminare la cartella e trovare nuovi file. Lo script invia quindi un messaggio di posta elettronica usando una cassetta postale protetta da un'API risorsa, Microsoft Graph.
Lo script viene eseguito senza alcuna interazione dell'utente, pertanto il sistema di autorizzazione controlla solo l'autorizzazione dell'applicazione. Exchange Online controlla se al client che effettua la chiamata è stata concessa l'autorizzazione dell'applicazione (ruolo app) Mail.Send dall'amministratore. Se Mail.Send non viene concesso all'app, Exchange Online non riesce la richiesta.
| POST /users/{id}/{userPrincipalName}/sendMail | App client concessa Mail.Send | App client non concessa Mail.Send |
|---|---|---|
| Lo script usa la cassetta postale di Alice per inviare messaggi di posta elettronica. | 200 : accesso concesso. Amministrazione consentito all'app di inviare messaggi di posta elettronica come qualsiasi utente. | 403 - Non autorizzato. Amministrazione non ha consentito a questo client di inviare messaggi di posta elettronica. |
| Lo script crea una cassetta postale dedicata per l'invio di messaggi di posta elettronica. | 200 : accesso concesso. Amministrazione consentito all'app di inviare messaggi di posta elettronica come qualsiasi utente. | 403 - Non autorizzato. Amministrazione non ha consentito a questo client di inviare messaggi di posta elettronica. |
L'esempio fornito è una semplice illustrazione dell'autorizzazione dell'applicazione. Il servizio Exchange Online di produzione supporta molti altri scenari di accesso, ad esempio la limitazione delle autorizzazioni dell'applicazione a cassette postali di Exchange Online specifiche.