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

Servizio app di Azure offre funzionalità di autenticazione e autorizzazione incorporate (talvolta denominate "Easy Auth"), in modo da consentire l'accesso degli utenti e l'accesso ai dati scrivendo codice minimo o nessun codice nell'app Web, nell'API RESTful e nel back-end per dispositivi mobili eFunzioni 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 incorporata?

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à proprie. Tuttavia, è necessario assicurarsi che la soluzione rimanga aggiornata con gli aggiornamenti più recenti per sicurezza, protocollo e browser.

L'implementazione di una soluzione sicura per l'autenticazione (utenti che accedono agli utenti) e l'autorizzazione (fornendo l'accesso ai dati protetti) può richiedere un notevole impegno. È necessario assicurarsi di seguire le procedure consigliate e gli standard del settore e mantenere aggiornata l'implementazione. La funzionalità di autenticazione predefinita per il servizio app e il Funzioni di Azure consente di risparmiare tempo e impegno fornendo l'autenticazione predefinita con i 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 nemmeno codice specifico da usare.
  • È possibile eseguire l'integrazione con più provider di accesso. Ad esempio, Azure AD, Facebook, Google, Twitter.

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. I provider di identità seguenti sono disponibili per impostazione predefinita:

Provider Endpoint di accesso How-To guida
Microsoft Identity Platform /.auth/login/aad Accesso a Microsoft Identity Platform del servizio app
Facebook /.auth/login/facebook Accesso a Facebook del servizio app
Google /.auth/login/google Accesso google al servizio app
Twitter /.auth/login/twitter Accesso a Twitter del servizio app
Qualsiasi provider di Connessione OpenID /.auth/login/<providerName> Accesso OpenID del servizio Connessione 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 incorporata

Se si abilita questa funzionalità, tutte le richieste all'applicazione verranno reindirizzate automaticamente a HTTPS, indipendentemente dall'impostazione di configurazione del servizio app per applicare HTTPS. È possibile disabilitare questa opzione requireHttps con l'impostazione nella configurazione V2. Tuttavia, è consigliabile attenersi a HTTPS e assicurarsi che nessun token di sicurezza sia mai trasmesso su connessioni HTTP non sicure.

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

Nota

È consigliabile assegnare a ogni registrazione dell'app le proprie autorizzazioni 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.

An architecture diagram showing requests being intercepted by a process in the site sandbox which interacts with identity providers before allowing traffic to the deployed site

Il middleware della piattaforma gestisce diversi elementi 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 di identità nelle intestazioni della richiesta HTTP

Il modulo viene eseguito separatamente dal codice dell'applicazione e può essere configurato usando 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 basata su contenitori)

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 noto modello Diaa,interagisce con il traffico in ingresso per eseguire funzionalità simili a quelle Windows. Poiché non viene eseguito in-process, non è possibile alcuna integrazione diretta con framework specifici del linguaggio. Tuttavia, le informazioni rilevanti 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 nel servizio app a un'altra API REST nel servizio app o Funzioni di Azure possono essere autenticate usando il flusso indirizzato al server. Per altre informazioni, vedere Personalizzare gli account di accesso e le disconnessioni.

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 inserisce il token del provider in 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

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

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.

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 del 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 o HTTP 401 UnauthorizedHTTP 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 Azure AD può richiedere un token per l'applicazione 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 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,verranno visualizzati 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 dell'applicazione esistenti. Se si abilita la traccia delle richiestenon riuscite, è possibile visualizzare esattamente il ruolo che il modulo di autenticazione e autorizzazione potrebbe avere svolto in una richiesta non riuscita. Nei log di traccia cercare i riferimenti a un modulo denominato EasyAuthModule_32/64.

Altre risorse

Esempi: