Sviluppare una strategia di autorizzazioni delegate
Questo articolo consente agli sviluppatori di implementare l'approccio migliore per la gestione delle autorizzazioni nell'applicazione e lo sviluppo con i principi Zero Trust. Come descritto in Acquisire l'autorizzazione per accedere alle risorse, le autorizzazioni delegate vengono usate con l'accesso delegato per consentire a un'applicazione di agire per conto di un utente, accedendo solo a ciò che l'utente può accedere. Le autorizzazioni dell'applicazione vengono usate con accesso diretto per consentire a un'applicazione di accedere ai dati a cui è associata l'autorizzazione. Solo gli amministratori e i proprietari delle entità servizio possono fornire il consenso alle autorizzazioni dell'applicazione.
I modelli di autorizzazione e consenso fanno riferimento principalmente a un'applicazione. Il processo di autorizzazione e consenso non ha alcun controllo sulle operazioni che un utente può eseguire. Controlla le azioni che l'applicazione può eseguire.
Fare riferimento al diagramma venn seguente. Con le autorizzazioni delegate, esiste un'intersezione tra le operazioni consentite dall'utente e le operazioni consentite all'applicazione. Tale intersezione è l'autorizzazione effettiva da cui è associata l'applicazione. Ogni volta che si usa un'autorizzazione delegata, le autorizzazioni valide sono associate.
Ad esempio, l'applicazione con utenti davanti all'app ottiene l'autorizzazione per aggiornare il profilo di ogni utente nel tenant. Ciò non significa che chiunque esegua l'applicazione possa aggiornare il profilo di chiunque altro. Se l'amministratore decide di concedere l'applicazione User.ReadWrite.All, ritiene che l'applicazione stia eseguendo le operazioni corrette durante l'aggiornamento di qualsiasi profilo utente. L'app potrebbe registrare le modifiche e proteggere correttamente le informazioni. L'amministratore fa un giudizio di valore sull'applicazione, non sull'utente.
Approccio con privilegi minimi
Le API possono essere complesse. Le API semplici potrebbero non avere molte operazioni. API complesse come Microsoft Graph incapsulano molte richieste che un'applicazione potrebbe voler usare. Solo perché l'applicazione ha il diritto di leggere non significa che deve avere il diritto di aggiornare. Ad esempio, Microsoft Graph ha migliaia di API. Solo perché hai l'autorizzazione per leggere il profilo dell'utente, non c'è motivo per cui dovresti avere anche l'autorizzazione per eliminare tutti i file di OneDrive.
Gli sviluppatori devono:
- sapere quali API chiamano l'app.
- comprendere la documentazione dell'API e le autorizzazioni necessarie per l'API.
- usare l'autorizzazione minima possibile per eseguire le attività.
Le API spesso forniscono l'accesso agli archivi dati dell'organizzazione e attirano l'attenzione degli utenti malintenzionati che vogliono accedere a tali dati.
Valutare le autorizzazioni richieste per assicurarsi di cercare il set con privilegi minimi assoluti per eseguire il processo. Evitare di richiedere autorizzazioni con privilegi più elevati; Al contrario, è possibile eseguire con attenzione il numero elevato di autorizzazioni fornite dalle API come Microsoft Graph. Individuare e usare le autorizzazioni minime per soddisfare le esigenze. Se non si scrive codice per aggiornare il profilo dell'utente, non è necessario richiederlo per l'applicazione. Se si accede solo a utenti e gruppi, non si richiede l'accesso ad altre informazioni nella directory. Non si richiede l'autorizzazione per gestire l'indirizzo di posta elettronica dell'utente se non si scrive codice che accede alla posta elettronica utente.
Nello sviluppo di applicazioni Zero Trust:
- Definire l'intenzione dell'applicazione e le esigenze.
- Assicurarsi che gli attori malintenzionati non possano compromettere e usare l'app in modo che non si intende.
- Effettuare richieste di approvazione in cui si definiscono i requisiti( ad esempio, leggere la posta dell'utente).
Ruoli di amministratore di utenti e tenant nell'autorizzazione e nel consenso
Persone chi può approvare le richieste rientra in due categorie: amministratori che possono sempre fornire il consenso alle richieste di autorizzazione e agli utenti normali che non sono amministratori. Tuttavia, gli amministratori tenant hanno la parola finale nel tenant per quanto riguarda quali autorizzazioni richiedono il consenso dell'amministratore e a quali autorizzazioni un utente può fornire il consenso.
Quando una finestra di progettazione API richiede il consenso amministratore per un'autorizzazione, tale autorizzazione richiede sempre il consenso amministratore. Un amministratore tenant non può annullare questa operazione e richiedere solo il consenso dell'utente.
Quando una finestra di progettazione API definisce le autorizzazioni che richiedono il consenso dell'utente, l'amministratore del tenant può sovrapporre i suggerimenti di consenso utente di Progettazione API. Gli amministratori tenant possono farlo con un "passaggio importante" nel tenant: tutto richiede il consenso dell'amministratore. Possono sovraruolere il consenso dell'utente in modo più granulare con la gestione delle autorizzazioni e del consenso. Ad esempio, potrebbero consentire agli utenti di fornire il consenso alle richieste di consenso degli utenti da autori verificati, ma non da altri editori. In un altro esempio, possono consentire User.Read l'accesso all'utente e leggere il proprio profilo, ma richiedono il consenso dell'amministratore per le app che richiedono l'autorizzazione per la posta elettronica o per i file.
I progettisti di API fanno i loro suggerimenti, ma gli amministratori tenant hanno la parola finale. Pertanto, in qualità di sviluppatore, non si sa sempre quando l'app richiede il consenso amministratore. È bello pianificare e progettare intorno a questo, ma ricordare, quando si effettua una richiesta di token, potrebbe essere negato per qualsiasi motivo. Nel codice è necessario gestire correttamente il mancato recupero di un token perché gli amministratori tenant in cui i clienti o gli utenti eseguono l'applicazione decidono quando le autorizzazioni richiedono il consenso amministratore.
Esempio di utilizzo di JAVAScript MSAL
Per l'autenticazione in questo esempio, si usa JavaScript Microsoft Authentication Library (MSAL) per accedere all'utente in un'applicazione a pagina singola (SPA) in cui viene eseguita tutta la logica dell'app dal browser.
Dall'articolo di avvio rapido correlato è possibile scaricare ed eseguire un esempio di codice. Illustra in che modo un'applicazione a pagina singola JavaScript può accedere agli utenti e chiamare Microsoft Graph usando il flusso del codice di autorizzazione con Proof Key for Code Exchange (PKCE). L'esempio di codice mostra come ottenere un token di accesso per chiamare l'API Microsoft Graph o qualsiasi API Web.
Come illustrato nel codice di esempio seguente, si crea un'istanza di un client pubblico perché un'applicazione eseguita interamente nel browser deve essere un client pubblico. L'utente può ottenere le mani sugli interni dell'applicazione quando il codice si trova nel browser.
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);
Quindi si usa la libreria MSAL. In MSAL JavaScript è disponibile un'API specifica per l'accesso. Esistono due API che usano funzionalità specifiche all'interno del browser. Uno consiste nell'accedere con un'esperienza popup; l'altro consiste nell'accedere con un'esperienza di reindirizzamento del browser.
Come illustrato nell'esempio di codice seguente, il popup di accesso gestisce l'autenticazione che l'utente deve eseguire chiamando la signIn funzione.
function signIn() {
/**
* You can pass a custom request object. This overrides the initial configuration. For more information, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
*/
myMSALObj.loginPopup(loginRequest)
.then(handleResponse)
.catch(error => {
console.error(error);
});
}
L'app può ottenere informazioni sull'utente, ad esempio il nome visualizzato o l'ID utente. Successivamente, l'app deve disporre dell'autorizzazione per leggere il profilo completo dell'utente da Microsoft Graph seguendo un modello usato in tutte le librerie MSAL.
Come illustrato nel codice di esempio seguente, l'app tenta di ottenere l'autorizzazione chiamando AcquireTokenSilent. Se Microsoft Entra ID può rilasciare il token senza interagire con l'utente, AcquireTokenSilent restituisce il token che l'app deve accedere a Microsoft Graph per conto dell'utente.
function getTokenPopup(request) {
/**
* See here for more info on account retrieval:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
*/
request.account = myMSALObj.getAccountByUsername(username);
return myMSALObj.`AcquireTokenSilent`(request)
.catch(error => {
console.warn("silent token acquisition fails. acquiring token using popup");
if (error instanceof msal.InteractionRequiredAuthError) {
// fallback to interaction when silent call fails
return myMSALObj.`AcquireTokenPopup`(request)
.then(tokenResponse => {
console.log(tokenResponse);
return tokenResponse;
}).catch(error => {
console.error(error);
});
} else {
console.warn(error);
}
});
}
Tuttavia, spesso Microsoft Entra ID non può rilasciare il token senza interagire con l'utente (ad esempio, l'utente ha modificato la password o non concede il consenso). Pertanto, AcquireTokenSilent invia un errore all'applicazione che richiede l'interazione dell'utente. Quando l'app riceve l'errore, viene eseguito il fallback per chiamare AcquireTokenPopup.
A questo punto, Microsoft Entra ID ha una conversazione con l'utente in modo da poter autenticare l'utente e autorizzare l'app ad agire per conto dell'utente (ad esempio, eseguire un'autenticazione a più fattori, fornire la password, concedere il consenso). L'app ottiene quindi il token necessario per procedere.
Un passaggio principale del percorso di un'azienda verso Zero Trust consiste nell'adottare metodi di autenticazione più avanzati anziché solo un ID utente e una password. Il codice di esempio precedente consente a un'azienda di passare al metodo di autenticazione più efficace scelto dall'organizzazione. Ad esempio, l'autenticazione a più fattori, completamente senza password con una chiave FIDO2, Microsoft Authenticator.
Passaggi successivi
- 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.
- Sviluppare una strategia di autorizzazioni per le applicazioni consente di decidere l'approccio alle autorizzazioni dell'applicazione per la gestione delle credenziali.
- 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.
- Protezione API descrive le procedure consigliate per proteggere l'API tramite la registrazione, la definizione di autorizzazioni e il consenso e l'applicazione dell'accesso per raggiungere gli obiettivi zero trust.
- 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.
- Le procedure consigliate per l'autorizzazione consentono di implementare i modelli di autorizzazione, autorizzazione e consenso ottimali per le applicazioni.
- 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.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per