Condividi tramite

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

  • Articolo

Nota

A partire dal 1° giugno 2024, tutte le app del Servizio app di Azure appena create avranno la possibilità di generare un nome host predefinito univoco usando la convenzione di denominazione <app-name>-<random-hash>.<region>.azurewebsites.net. I nomi delle app esistenti rimarranno invariati.

Esempio: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Per altri dettagli, vedere Nome host predefinito univoco per la risorsa del Servizio app di Azure.

Il Servizio app di Azure fornisce funzionalità di autenticazione e autorizzazione integrate (a volte denominate "Autenticazione facile") ed è quindi possibile consentire l'accesso degli utenti e l'accesso ai dati senza scrivere codice, o con una minima quantità di codice, nell'app Web, nell'API RESTful, nel back-end per dispositivi mobili e anche in 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?

L'uso di questa funzionalità per l'autenticazione e l'autorizzazione non è obbligatorio. È 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:

Provider Endpoint di accesso Guida alle procedure
Microsoft Entra /.auth/login/aad Accesso alla piattaforma Microsoft Entra del Servizio app di Azure
Facebook /.auth/login/facebook Accesso tramite Facebook per Servizio app
Google /.auth/login/google Accesso tramite Google per Servizio app
Twitter /.auth/login/twitter Accesso tramite Twitter per Servizio app
GitHub /.auth/login/github Accesso GitHub del servizio app
Accedere con Apple /.auth/login/apple Accesso al Servizio app di Azure con l'account di accesso Apple (anteprima)
Qualsiasi provider di OpenID Connect /.auth/login/<providerName> Accesso tramite OpenID Connect per Servizio app

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

Considerazioni sull'uso dell'autenticazione predefinita

Se si abilita questa funzionalità, tutte le richieste all'applicazione verranno reindirizzate automaticamente a HTTPS, indipendentemente dall'impostazione di configurazione del Servizio app di Azure 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.

Il Servizio app di Azure 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 Autenticazione> 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)."

Importante

È consigliabile concedere a ogni app la propria autorizzazione e il proprio consenso. Evitare la condivisione delle autorizzazioni tra ambienti usando registrazioni di app separate per slot di distribuzione distinti. Quando si esegue il test di nuovo codice, questa procedura consente di evitare problemi che influiscono sull'app di produzione.

Funzionamento

Architettura delle funzionalità

Flusso di autenticazione

Comportamento di 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 è abilitato, ogni richiesta HTTP in ingresso passa attraverso tale modulo prima di essere gestita dall'applicazione.

Diagramma dell'architettura che mostra le richieste intercettate da un processo nella sandbox del sito che interagisce con i provider di identità prima di consentire il traffico verso il sito distribuito

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 usando 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 nello stesso ambiente sandbox dell'applicazione. Quando è abilitato, ogni richiesta HTTP in ingresso passa attraverso tale modulo 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 motivo Ambassador, interagisce con il traffico in ingresso per eseguire funzionalità simili come in 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 nel Servizio app di Azure a un'altra API REST nel Servizio app di Azure o in Funzioni di Azure possono essere autenticate tramite il flusso diretto dal server. Per altre informazioni, vedere Personalizzare gli accessi e le disconnessioni.

La tabella seguente illustra i passaggi del flusso di autenticazione.

Passaggio Senza SDK del provider Con SDK del provider
1. Consentire l'accesso utente Reindirizza il client a /.auth/login/<provider>. Il codice client consente l'accesso utente direttamente con l'SDK del provider e riceve un token di autenticazione. Per informazioni, vedere la documentazione del provider.
2. Eseguire le operazioni successive all'autenticazione Il provider reindirizza il client a /.auth/login/<provider>/callback. Il codice client inserisce il token del provider in /.auth/login/<provider> per la convalida.
3. Stabilire la sessione autenticata Il servizio app aggiunge il cookie autenticato alla risposta. Il servizio app restituisce il proprio token di autenticazione al codice client.
4. Fornire contenuto autenticato Il client include il cookie di autenticazione nelle richieste successive (gestite automaticamente dal browser). Il codice client presenta il token di autenticazione nell'intestazione X-ZUMO-AUTH.

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

Importante

Per impostazione predefinita, questa funzionalità fornisce solo l'autenticazione, non l'autorizzazione. L'applicazione potrebbe comunque dover prendere decisioni di autorizzazione, oltre a eventuali controlli configurati qui.

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

Limitare l'accesso

  • 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 desidera 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 Dati principali sull'autorizzazione di Microsoft Entra.

Richieste non autenticate

  • HTTP 302 Reindirizzamento trovato: scelta consigliata 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 HTTP 403 Forbidden per 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 da parte degli utenti associati.

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 il Servizio app di Azure con l'autenticazione semplice 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

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

  3. Assicurarsi che il Servizio app di Azure usi l'URI di reindirizzamento corretto

    In alcune configurazioni, il Servizio app di Azure usa il nome di dominio completo del Servizio app di Azure come URI di reindirizzamento anziché l'FQDN Frontdoor. Questo causerà un problema quando il client viene reindirizzato al Servizio app di Azure invece di Frontdoor. Per modificare questa impostazione, l'impostazione forwardProxy deve essere impostata su Standard per fare in modo che il Servizio app di Azure rispetti l'intestazione X-Forwarded-Host impostata da Frontdoor di Azure.

    Altri proxy inversi, ad esempio il gateway applicazione di Azure o i prodotti di terze parti, possono usare intestazioni diverse e richiedono un'impostazione forwardProxy diversa.

    Questa configurazione non può essere eseguita oggi tramite il portale di Azure 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 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

Esempi: