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

Servizio app di Azure offre funzionalità predefinite di autenticazione e autorizzazione (talvolta denominate "Autenticazione semplice"), in modo da poter accedere agli utenti e accedere ai dati scrivendo codice minimo o senza 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, Azure AD, Facebook, Google, Twitter.

Provider di identità

servizio app usa l'identità federata, in cui un provider di identità di terze parti gestisce automaticamente 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 Identity Platform /.auth/login/aad Accesso tramite Microsoft Identity Platform per Servizio app
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
Qualsiasi provider OpenID Connect /.auth/login/<providerName> Accesso tramite OpenID Connect per Servizio app

Quando si abilitano l'autenticazione e l'autorizzazione 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

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 impostazione 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. Per limitare l'accesso alle app solo agli utenti autenticati, impostare Azione da eseguire quando la richiesta non viene autenticata per accedere con uno dei provider di identità configurati. Per autenticare ma non limitare l'accesso, impostare Azione da eseguire quando la richiesta non viene autenticata su "Consenti richieste anonime (nessuna azione)."

Nota

È consigliabile assegnare 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 di token

Registrazione e traccia

Architettura delle funzionalità

Il componente middleware di autenticazione e autorizzazione è una funzionalità della piattaforma eseguita nella stessa macchina virtuale dell'applicazione. Quando è abilitata, ogni richiesta HTTP in ingresso passa attraverso di essa 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 sull'identità nelle intestazioni di richiesta 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 al 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 eseguita 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 SDK del provider: l'applicazione delega l'accesso federato al servizio app. Ciò avviene, in genere, con le app basate su 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 basate su browser. Si applica anche alle app native che consentono l'accesso agli utenti con l'SDK client di App per dispositivi mobili, perché l'SDK consente di aprire una visualizzazione Web per l'accesso degli utenti con l'autenticazione del servizio app.
  • Con l'SDK del provider: l'applicazione consente l'accesso manuale degli utenti al provider e quindi invia il token di autenticazione al servizio app per la convalida. Ciò avviene, in genere, con le 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 dal server. Per altre informazioni, vedere Personalizzare gli accessi e le disconnesse.

La tabella seguente illustra i passaggi del flusso di autenticazione.

Passaggio Senza SDK del provider Con SDK del provider
1. Accedere all'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. Post-autenticazione Il provider reindirizza il client a /.auth/login/<provider>/callback. Il codice client invia il token dal provider a /.auth/login/<provider> per la convalida.
3. Stabilire una sessione autenticata Il servizio app aggiunge il cookie autenticato alla risposta. Il servizio app restituisce il proprio token di autenticazione al codice client.
4. Gestire il 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 (gestita automaticamente dagli SDK client per app per dispositivi mobili).

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 di autorizzazione

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

Consentire le 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.

Richiedere l'autenticazione

Questa opzione rifiuterà qualsiasi traffico non autenticato verso l'applicazione. Questo rifiuto può essere un'azione di reindirizzamento a uno dei provider di identità configurati. In questi casi, un client browser viene reindirizzato a /.auth/login/<provider> per il provider scelto. Se la richiesta anonima proviene da un'app per dispositivi mobili nativa, verrà restituita la risposta HTTP 401 Unauthorized. È anche possibile configurare il rifiuto come HTTP 401 Unauthorized o HTTP 403 Forbidden per tutte le richieste.

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

Per impostazione predefinita, qualsiasi utente nel tenant di Azure AD può richiedere un token per l'applicazione da Azure AD. È possibile configurare l'applicazione in Azure AD se si vuole limitare l'accesso all'app a un set definito di utenti.

Archivio di token

Il servizio app fornisce un archivio di token predefinito, ovvero un repository di token associati agli utenti delle app Web, delle API o delle app per dispositivi mobili native. 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 Microsoft API 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, verranno visualizzate le tracce di autenticazione e autorizzazione direttamente nei file di log. Se viene visualizzato un errore di autenticazione non previsto, è possibile trovare facilmente tutti i dettagli esaminando i log applicazioni esistenti. Se si abilita la traccia delle richieste non riuscite, è possibile visualizzare esattamente il ruolo che il modulo di autenticazione e autorizzazione potrebbe avere avuto in una richiesta non riuscita. Nei log di traccia cercare i riferimenti a un modulo denominato EasyAuthModule_32/64.

Considerazioni sull'uso di Frontdoor di Azure

Quando si usa Servizio app di Azure 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 il nome di dominio completo servizio app come URI di reindirizzamento anziché il nome di dominio completo frontdoor. Ciò causerà un problema quando il client viene reindirizzato a servizio app invece di Frontdoor. Per modificarla, l'impostazione forwardProxy deve essere impostata su Standard per rendere servizio app rispettare l'intestazione X-Forwarded-Host impostata da Frontdoor di Azure.

    Altri proxy inversi, ad esempio gateway applicazione di Azure 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:

    Esportazione impostazioni

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

    Aggiornamento delle impostazioni

    Ricerca

    "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?api-version=2020-09-01 --method put --body @auth.json

Altre risorse

Esempi: