Informazioni sull'accesso solo app
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 applicazione.
Quando è consigliabile usare l'accesso solo applicazione?
Nella maggior parte dei casi, l'accesso solo 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" utente o amministratore.
Al contrario, è consigliabile non usare mai l'accesso solo 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 all'applicazione il 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 attività 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 solo app necessarie, 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 runtime.
Dopo aver configurato tutte le autorizzazioni necessarie per l'app, deve ottenere il consenso amministratore per accedere alle risorse. Ad esempio, solo gli utenti con almeno il ruolo Amministratore ruolo con privilegi possono concedere autorizzazioni solo app (ruoli dell'app) per l'API Microsoft Graph. Gli utenti con altri ruoli di amministratore, ad esempio Amministratore di applicazioni e Amministratore applicazione cloud, possono concedere autorizzazioni solo app per altre risorse.
Gli utenti amministratori 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 Xbox Live, non possono mai autorizzare l'accesso solo all'applicazione.
Attenersi sempre al principio dei privilegi minimi: non si devono 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 agli amministratori concedere l'accesso all'app. Ad esempio, se l'app deve identificare gli utenti senza leggere le informazioni dettagliate sul profilo, è necessario richiedere invece User.ReadBasic.Allil ruolo dell'app User.Read.All più limitato di Microsoft Graph .
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 dell'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 l'uso da parte di altri utenti, fornire descrizioni chiare dello scenario all'amministratore che li assegnerà. I ruoli dell'app devono in genere essere il più stretti possibile e supportaro scenari funzionali specifici, poiché l'accesso solo app non è vincolato dai diritti utente. Evitare di esporre un singolo ruolo che concede l'accesso completo reado completoread/write a tutte le API e alle risorse contenute nel servizio.
Nota
I ruoli dell'app (autorizzazioni solo app) possono anche essere configurati in modo da 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 dell'accesso solo app è che l'app chiamante agisce per proprio conto e come propria identità. Non c'è nessuna interazione dell'utente. Se l'app è stata assegnata a un determinato ruolo dell'app per una risorsa, in tal caso 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 delle credenziali client o qualsiasi altro flusso di autenticazione supportato. I ruoli assegnati vengono aggiunti rolesall'attestazione 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 dell'app concede a un'app la possibilità di gestire le entità servizio di proprietà dell'app stessa.
Esempio di accesso solo applicazione - Notifica tramite messaggio di posta elettronica automatizzata tramite Microsoft Graph
Lo scenario di automazione realistico è illustrato nell'esempio seguente.
Alice vuole inviare una notifica tramite messaggio di 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 concessa all'app, Exchange Online dà esito negativo alla 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. L'amministratore ha consentito all'app di inviare messaggi di posta elettronica come qualsiasi utente. | 403 - Non autorizzato. L'amministratore 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. L'amministratore ha consentito all'app di inviare messaggi di posta elettronica come qualsiasi utente. | 403 - Non autorizzato. L'amministratore 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.