Autenticazione e autorizzazione nel Servizio app di Azure e Funzioni di Azure

app Azure Servizio offre funzionalità di autenticazione e autorizzazione predefinite (talvolta denominate "Easy Auth"), in modo da poter accedere agli utenti e accedere ai dati scrivendo codice minimo o nessun codice nell'app Web, nell'API RESTful e nel back-end per dispositivi mobili e anche Funzioni di Azure. Questo articolo descrive in che modo il servizio app aiuta a semplificare l'autenticazione e l'autorizzazione per l'app.

Perché usare l'autenticazione predefinita?

Non è necessario usare questa funzionalità per l'autenticazione e l'autorizzazione. È possibile usare le funzionalità di sicurezza in bundle nel framework Web preferito oppure scrivere utilità personalizzate. Tuttavia, è necessario assicurarsi che la soluzione rimanga aggiornata con gli aggiornamenti più recenti di sicurezza, protocollo e browser.

L'implementazione di una soluzione sicura per l'autenticazione (accesso degli utenti) e l'autorizzazione (accesso ai dati sicuri) può richiedere notevoli sforzi. È necessario assicurarsi di seguire le procedure consigliate e gli standard del settore e mantenere aggiornata l'implementazione. La funzionalità di autenticazione predefinita per Servizio app e Funzioni di Azure consente di risparmiare tempo e fatica fornendo l'autenticazione immediata con provider di identità federati, consentendo di concentrarsi sul resto dell'applicazione.

• Servizio app di Azure consente di integrare un'ampia gamma di funzionalità di autenticazione nell'app Web o nell'API senza implementarle manualmente.
• È integrato direttamente nella piattaforma e non richiede alcun linguaggio, SDK, esperienza di sicurezza o codice specifico da usare.
• È possibile eseguire l'integrazione con più provider di accesso. Ad esempio, Microsoft Entra, Facebook, Google, Twitter.

L'app potrebbe dover supportare scenari più complessi, ad esempio l'integrazione di Visual Studio o il consenso incrementale. Sono disponibili diverse soluzioni di autenticazione per supportare questi scenari. Per altre informazioni, vedere Scenari di identità.

Provider di identità

Il servizio app usa l'identità federata, in cui un provider di identità di terze parti gestisce le identità utente e il flusso di autenticazione. Per impostazione predefinita, sono disponibili i provider di identità seguenti:

Quando si configura questa funzionalità con uno di questi provider, l'endpoint di accesso è disponibile per l'autenticazione utente e per la convalida dei token di autenticazione dal provider. È possibile fornire agli utenti un numero qualsiasi di queste opzioni di accesso.

Considerazioni sull'uso dell'autenticazione predefinita

L'abilitazione di questa funzionalità causerà il reindirizzamento automatico di tutte le richieste all'applicazione a HTTPS, indipendentemente dall'impostazione di configurazione servizio app per applicare HTTPS. È possibile disabilitare questa opzione con l'impostazione requireHttps nella configurazione V2. Tuttavia, è consigliabile attenersi a HTTPS e assicurarsi che non vengano mai trasmessi token di sicurezza tramite connessioni HTTP non sicure.

servizio app può essere usato per l'autenticazione con o senza limitare l'accesso al contenuto e alle API del sito. Le restrizioni di accesso possono essere impostate nella sezione Impostazioni di autenticazione>dell'app Web. Per limitare l'accesso alle app solo agli utenti autenticati, impostare Azione da eseguire quando la richiesta non è autenticata per accedere con uno dei provider di identità configurati. Per eseguire l'autenticazione ma non limitare l'accesso, impostare Azione da eseguire quando la richiesta non viene autenticata su "Consenti richieste anonime (nessuna azione)."

Funzionamento

Architettura delle funzionalità

Flusso di autenticazione

Comportamento dell'autorizzazione

Archivio token

Registrazione e traccia

Architettura delle funzionalità

Il componente middleware di autenticazione e autorizzazione è una funzionalità della piattaforma in esecuzione nella stessa macchina virtuale dell'applicazione. Quando è abilitata, ogni richiesta HTTP in ingresso passa attraverso di essa prima di essere gestita dall'applicazione.

Il middleware della piattaforma gestisce diversi aspetti per l'app:

• Autentica utenti e client con i provider di identità specificati
• Convalida, archivia e aggiorna i token OAuth emessi dai provider di identità configurati
• Gestisce la sessione autenticata
• Inserisce le informazioni relative all'identità nelle intestazioni delle richieste HTTP

Il modulo viene eseguito separatamente dal codice dell'applicazione e può essere configurato usando le impostazioni di Azure Resource Manager o un file di configurazione. Non sono necessari SDK, linguaggi di programmazione specifici o modifiche del codice dell'applicazione.

Architettura delle funzionalità in Windows (distribuzione non contenitore)

Il modulo di autenticazione e autorizzazione viene eseguito come modulo IIS nativo nella stessa sandbox dell'applicazione. Quando è abilitata, ogni richiesta HTTP in ingresso passa attraverso di essa prima di essere gestita dall'applicazione.

Architettura delle funzionalità in Linux e contenitori

Il modulo di autenticazione e autorizzazione viene eseguito in un contenitore separato, isolato dal codice dell'applicazione. Usando il modello Ambassador, interagisce con il traffico in ingresso per eseguire funzionalità simili a quella di Windows. Poiché non viene eseguito in-process, non è possibile eseguire l'integrazione diretta con framework di linguaggio specifici; Tuttavia, le informazioni pertinenti necessarie per l'app vengono passate usando le intestazioni della richiesta, come illustrato di seguito.

Flusso di autenticazione

Il flusso di autenticazione è uguale per tutti i provider, ma varia a in base al fatto che si desideri o meno accedere con l'SDK del provider:

• Senza provider SDK: l'applicazione delega l'accesso federato al servizio app. Questo è in genere il caso delle app del browser, che possono presentare all'utente la pagina di accesso del provider. Il codice server gestisce il processo di accesso, quindi si parla anche di flusso diretto dal server oppure flusso server. Questo caso si applica alle app browser e alle app per dispositivi mobili che usano un browser incorporato per l'autenticazione.
• Con provider SDK: l'applicazione consente agli utenti di accedere manualmente al provider e quindi invia il token di autenticazione al servizio app per la convalida. Questo è in genere il caso delle app senza browser, che non possono presentare all'utente la pagina di accesso del provider. Il codice dell'applicazione gestisce il processo di accesso, quindi si parla anche di flusso diretto dal client oppure flusso client. Questo caso si applica alle API REST, a Funzioni di Azure e ai client browser JavaScript, oltre che alle app basate su browser che richiedono una maggiore flessibilità nel processo di accesso. Si applica anche alle app per dispositivi mobili native che consentono l'accesso degli utenti con l'SDK del provider.

Le chiamate da un'app browser attendibile in servizio app a un'altra API REST in servizio app o Funzioni di Azure possono essere autenticate usando il flusso diretto al server. Per altre informazioni, vedere Personalizzare gli accessi e le disconnessazioni.

La tabella seguente illustra i passaggi del flusso di autenticazione.

Per i browser client, il servizio app può indirizzare automaticamente tutti gli utenti non autenticati a /.auth/login/<provider>. È anche possibile presentare agli utenti uno o più collegamenti a /.auth/login/<provider> per consentire di accedere all'app con il provider desiderato.

Comportamento dell'autorizzazione

Nella portale di Azure è possibile configurare servizio app con diversi comportamenti quando la richiesta in ingresso non è autenticata. I titoli seguenti descrivono le opzioni.

Accesso restrico

• Consenti richieste non autenticate Questa opzione rinvia l'autorizzazione del traffico non autenticato al codice dell'applicazione. Per le richieste autenticate, il servizio app passa anche le informazioni di autenticazione nelle intestazioni HTTP.

  Questa opzione offre maggiore flessibilità nella gestione delle richieste anonime. Ad esempio consente di presentare più opzioni di accesso agli utenti. Tuttavia richiede di scrivere codice.

• Richiedi autenticazione Questa opzione rifiuterà qualsiasi traffico non autenticato per l'applicazione. L'azione specifica da eseguire viene specificata nella sezione Richieste non autenticate.

  Con questa opzione non è necessario scrivere codice di autenticazione nell'app. È possibile gestire un livello di autorizzazione più specifico, ad esempio l'autorizzazione specifica dei ruoli, esaminando le attestazioni utente (vedere Accedere alle attestazioni utente).

  Attenzione

  La limitazione dell'accesso in questo modo si applica a tutte le chiamate all'app, il che potrebbe non essere opportuno per le app che desiderano una home page disponibile pubblicamente, come nel caso di molte applicazioni a pagina singola.

  Nota

  Quando si usa il provider di identità Microsoft per gli utenti dell'organizzazione, il comportamento predefinito è che qualsiasi utente nel tenant di Microsoft Entra può richiedere un token per l'applicazione. È possibile configurare l'applicazione in Microsoft Entra se si vuole limitare l'accesso all'app a un set definito di utenti. Il servizio app offre anche alcuni controlli di autorizzazione predefiniti di base che possono essere utili per alcune convalide. Per altre informazioni sull'autorizzazione in Microsoft Entra, vedere Nozioni di base sull'autorizzazione di Microsoft Entra.

Richieste non autenticate

• Reindirizzamento trovato HTTP 302: consigliato per i siti Web Reindirizza l'azione a uno dei provider di identità configurati. In questi casi, un client browser viene reindirizzato a /.auth/login/<provider> per il provider scelto.
• HTTP 401 Non autorizzato: consigliato per le API Se la richiesta anonima proviene da un'app per dispositivi mobili nativa, la risposta restituita è un HTTP 401 Unauthorized. È anche possibile configurare il rifiuto come oggetto HTTP 401 Unauthorized per tutte le richieste.
• HTTP 403 Non consentito Configura il rifiuto come per HTTP 403 Forbidden tutte le richieste.
• HTTP 404 Non trovato Configura il rifiuto come oggetto HTTP 404 Not found per tutte le richieste.

Archivio token

Il servizio app offre un archivio di token predefinito, ovvero un repository di token associati agli utenti delle app Web, delle API o delle app native per dispositivi mobili. Quando si abilita l'autenticazione con qualsiasi provider, questo archivio di token diventa immediatamente disponibile per l'app. Se il codice dell'applicazione deve accedere ai dati di questi provider per conto dell'utente, ad esempio:

• pubblicare sul diario di Facebook dell'utente autenticato
• leggere i dati aziendali dell'utente usando l'API Microsoft Graph

In genere è necessario scrivere codice per raccogliere, archiviare e aggiornare questi token nell'applicazione. Con l'archivio di token, è sufficiente recuperare i token quando sono necessari e fare in modo che il servizio app li aggiorni quando non sono più validi.

I token ID, i token di accesso e i token di aggiornamento vengono memorizzati nella cache per la sessione autenticata e sono accessibili solo dall'utente associato.

Se non è necessario usare i token nell'app, è possibile disabilitare l'archivio token nella pagina Autenticazione/autorizzazione dell'app.

Registrazione e traccia

Se si abilita la registrazione delle applicazioni, le tracce di autenticazione e autorizzazione possono essere visualizzate direttamente nei file di log. Se viene visualizzato un errore di autenticazione non previsto, è possibile trovarne facilmente tutti i dettagli esaminando i log dell'applicazione esistenti. Se si abilita la traccia delle richieste non riuscite, è possibile vedere esattamente il ruolo che il modulo di autenticazione e autorizzazione ha avuto nella mancata riuscita della richiesta. Nei log di traccia cercare i riferimenti a un modulo denominato EasyAuthModule_32/64.

Considerazioni sull'uso di Frontdoor di Azure

Quando si usa app Azure Service con Easy Auth dietro Frontdoor di Azure o altri proxy inversi, è necessario prendere in considerazione alcuni aspetti aggiuntivi.

1. Disabilitare la memorizzazione nella cache per il flusso di lavoro di autenticazione

   Vedere Disabilitare la cache per il flusso di lavoro di autenticazione per altre informazioni su come configurare le regole in Frontdoor di Azure per disabilitare la memorizzazione nella cache per le pagine correlate all'autenticazione e all'autorizzazione.

2. Usare l'endpoint frontdoor per i reindirizzamenti

   servizio app in genere non è accessibile direttamente quando viene esposto tramite Frontdoor di Azure. Ciò può essere impedito, ad esempio, esponendo servizio app tramite collegamento privato in Frontdoor di Azure Premium. Per evitare che il flusso di lavoro di autenticazione reindirizzi il traffico a servizio app direttamente, è importante configurare l'applicazione per il reindirizzamento a https://<front-door-endpoint>/.auth/login/<provider>/callback.

3. Assicurarsi che servizio app stia usando l'URI di reindirizzamento corretto

   In alcune configurazioni, il servizio app usa l'FQDN servizio app come URI di reindirizzamento anziché l'FQDN frontdoor. Questo causerà un problema quando il client viene reindirizzato a servizio app invece di Frontdoor. Per modificarla, l'impostazione forwardProxy deve essere impostata su per Standard rendere servizio app rispettare l'intestazione X-Forwarded-Host impostata da Frontdoor di Azure.

   Altri proxy inversi come app Azure lication Gateway o prodotti di terze parti possono usare intestazioni diverse e richiedono un'impostazione forwardProxy diversa.

   Questa configurazione non può essere eseguita tramite il portale di Azure oggi e deve essere eseguita tramite az rest:

   Impostazioni di esportazione

   az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

   Aggiornare le impostazioni

   Cerca

   "httpSettings": {
     "forwardProxy": {
       "convention": "Standard"
     }
   }
   

   e assicurarsi che convention sia impostato su Standard per rispettare l'intestazione X-Forwarded-Host usata da Frontdoor di Azure.

   Importare le impostazioni

   az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Altre risorse

• Procedura: Configurare l'servizio app o l'app Funzioni di Azure per l'uso dell'account di accesso di Microsoft Entra
• Personalizzare gli accessi e le disconnettezioni

• Usare token e sessioni OAuth
• Accedere alle attestazioni utente e applicazione
• Configurazione basata su file

Esempi:

• Esercitazione: Aggiungere l'autenticazione all'app Web in esecuzione nel servizio app Azure
• Esercitazione: Autenticare e autorizzare gli utenti end-to-end nel servizio app Azure (Windows o Linux)
• Integrazione di .NET Core di app Azure Service EasyAuth (terza parte)
• Recupero dell'autenticazione del servizio app Azure con .NET Core (terze parti)