Autenticazione e autorizzazione in App Azure Container

  • Articolo

App Azure Container offre funzionalità predefinite di autenticazione e autorizzazione (talvolta denominata "Autenticazione semplice"), per proteggere l'app contenitore abilitata per l'ingresso esterno con codice minimo o senza codice.

Per informazioni dettagliate sull'autenticazione e l'autorizzazione, vedere le guide seguenti per la scelta del provider.

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, l'implementazione di una soluzione sicura per l'autenticazione (utenti di accesso) e l'autorizzazione (fornendo l'accesso ai dati sicuri) può richiedere un impegno significativo. È necessario assicurarsi di seguire le procedure consigliate e gli standard del settore e mantenere aggiornata l'implementazione.

La funzionalità di autenticazione predefinita per App contenitore consente di risparmiare tempo e impegno fornendo l'autenticazione predefinita con provider di identità federati. Queste funzionalità consentono di concentrarsi più tempo sullo sviluppo dell'applicazione e meno tempo per la creazione di sistemi di sicurezza.

I vantaggi includono:

  • App contenitore di Azure offre l'accesso a vari provider di autenticazione predefiniti.
  • Le funzionalità di autenticazione predefinite non richiedono un linguaggio particolare, un SDK, competenze in materia di sicurezza o addirittura codice da scrivere.
  • È possibile eseguire l'integrazione con più provider, tra cui Microsoft Entra ID, Facebook, Google e X.

Provider di identità

App contenitore 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 Microsoft Identity Platform
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
X /.auth/login/x X
Qualsiasi provider di OpenID Connect /.auth/login/<providerName> OpenID Connect

Quando si usa uno di questi provider, l'endpoint di accesso è disponibile per l'autenticazione utente e per la convalida dei token di autenticazione da parte del provider. È possibile fornire agli utenti un numero qualsiasi di queste opzioni di provider.

Considerazioni sull'uso dell'autenticazione predefinita

Questa funzionalità deve essere usata solo con HTTPS. Assicurarsi che allowInsecure sia disabilitato nella configurazione in ingresso dell'app contenitore.

È possibile configurare l'app contenitore per l'autenticazione con o senza limitare l'accesso al contenuto del sito e alle API. Per limitare l'accesso all'app solo agli utenti autenticati, impostare l'impostazione Limita l'accesso su Richiedi autenticazione. Per eseguire l'autenticazione ma non limitare l'accesso, impostare l'impostazione Limita l'accesso su Consenti accesso non autenticato.

Per impostazione predefinita, ogni app contenitore rilascia un proprio cookie o token univoco per l'autenticazione. È anche possibile fornire chiavi di firma e crittografia personalizzate.

Architettura delle funzionalità

Il componente middleware di autenticazione e autorizzazione è una funzionalità della piattaforma che viene eseguita come contenitore sidecar in ogni replica dell'applicazione. Se abilitata, l'applicazione gestisce ogni richiesta HTTP in ingresso dopo che passa attraverso il livello di sicurezza.

Diagramma dell'architettura che mostra le richieste intercettate da un contenitore sidecar che interagisce con i provider di identità prima di consentire il traffico verso il contenitore dell'app

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

  • Autentica utenti e client con i provider di identità specificati
  • Gestisce la sessione autenticata
  • Inserisce le informazioni relative all'identità nelle intestazioni delle richieste HTTP

Il modulo di autenticazione e autorizzazione viene eseguito in un contenitore separato, isolato dal codice dell'applicazione. Poiché il contenitore di sicurezza 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 fornite nelle intestazioni delle richieste, come illustrato in questo articolo.

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 (flusso diretto dal server o flusso del server): l'applicazione delega l'accesso federato ad App contenitore. La delega avviene in genere con le app del browser, che visualizzano la pagina di accesso del provider.

  • Con provider SDK (flusso diretto dal client o flusso client): l'applicazione consente agli utenti di accedere manualmente al provider e quindi invia il token di autenticazione ad App contenitore per la convalida. Questo approccio è tipico per le app senza browser che non visualizzano la pagina di accesso del provider. Un esempio è un'app per dispositivi mobili nativa che consente agli utenti di usare l'SDK del provider.

Le chiamate da un'app browser attendibile in App contenitore a un'altra API REST in App contenitore possono essere autenticate usando il flusso diretto al server. Per altre informazioni, vedere Personalizzare l'accesso e la disconnessa.

La tabella mostra 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 App contenitore aggiunge cookie autenticati alla risposta. App contenitore 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, App contenitore 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 modificare le impostazioni di autenticazione dell'app contenitore per configurarla con diversi comportamenti quando una richiesta in ingresso non viene autenticata. I titoli seguenti descrivono le opzioni.

  • Consenti accesso non autenticato: questa opzione rinvia l'autorizzazione del traffico non autenticato al codice dell'applicazione. Per le richieste autenticate, App contenitore passa anche informazioni di autenticazione nelle intestazioni HTTP. L'app può usare le informazioni nelle intestazioni per prendere decisioni di autorizzazione per una richiesta.

    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 rifiuta tutto il 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 Microsoft Entra può richiedere un token per l'applicazione da Microsoft Entra ID. È possibile configurare l'applicazione in Microsoft Entra ID se si vuole limitare l'accesso all'app a un set definito di utenti.

Personalizzare l'accesso e la disconnessa

L'autenticazione di App contenitore offre endpoint predefiniti per l'accesso e la disconnessità. Quando la funzionalità è abilitata, questi endpoint sono disponibili con il prefisso di route nell'app /.auth contenitore.

Usare più provider di accesso

La configurazione del portale non offre un modo chiavi in mano per presentare più provider di accesso agli utenti , ad esempio Facebook e X. È tuttavia possibile aggiungere facilmente questa funzionalità all'app. Seguire questa procedura:

Prima di tutto, nella pagina Autenticazione/Autorizzazione nel portale di Azure configurare ogni provider di identità che si vuole abilitare.

In Azione da eseguire quando la richiesta non è autenticata selezionare Consenti richieste anonime (nessuna azione).

Nella pagina di accesso, sulla barra di spostamento o in qualsiasi altra posizione nell'app aggiungere un collegamento per l'accesso a ognuno dei provider abilitati (/.auth/login/<provider>). Ad esempio:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

Quando l'utente seleziona uno dei collegamenti, l'interfaccia utente per i rispettivi provider viene visualizzata all'utente.

Per reindirizzare l'utente dopo l'accesso a un URL personalizzato, usare il parametro della stringa di query post_login_redirect_uri, da non confondere con l'URI di reindirizzamento nella configurazione del provider di identità. Ad esempio, per passare l'utente a /Home/Index dopo l'accesso, usare il seguente codice HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Accesso diretto dal client

In un accesso diretto dal client, l'applicazione esegue l'accesso dell'utente al provider di identità usando un SDK specifico del provider. Il codice dell'applicazione invia quindi il token di autenticazione risultante ad App contenitore per la convalida (vedere Flusso di autenticazione) usando una richiesta HTTP POST.

Per convalidare il token del provider, l'app contenitore deve prima essere configurata con il provider desiderato. In fase di esecuzione, dopo aver recuperato il token di autenticazione dal provider, inviare il token a /.auth/login/<provider> per la convalida. Ad esempio:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Il formato del token varia leggermente in base al provider. Per informazioni dettagliate, vedere la tabella seguente:

Valore provider Obbligatorio nel corpo della richiesta Commenti
aad {"access_token":"<ACCESS_TOKEN>"} Le proprietà id_token, refresh_token e expires_in sono facoltative.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} oppure {"authentication_token": "<TOKEN>" authentication_token è preferibile rispetto a access_token. La proprietà expires_in è facoltativa.
Quando si richiede il token da servizi Live, richiedere sempre l'ambito wl.basic.
google {"id_token":"<ID_TOKEN>"} La proprietà authorization_code è facoltativa. Se si specifica un authorization_code valore, viene aggiunto un token di accesso e un token di aggiornamento all'archivio token. Se specificato, authorization_code può anche essere accompagnato facoltativamente da una proprietà redirect_uri.
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Usare un token di accesso valido dell'utente da Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Se il token del provider viene convalidato, l'API restituisce un token authenticationToken nel corpo della risposta, che corrisponde al token di sessione.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Dopo aver ottenuto il token di sessione, è possibile accedere alle risorse dell'app protette aggiungendo l'intestazione X-ZUMO-AUTH alle richieste HTTP. Ad esempio:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Disconnettersi da una sessione

Gli utenti possono disconnettersi inviando una GET richiesta all'endpoint dell'app /.auth/logout . La GET richiesta esegue le azioni seguenti:

  • Cancella i cookie di autenticazione dalla sessione corrente.
  • Elimina i token dell'utente corrente dall'archivio di token.
  • Esegue un disconnesso lato server nel provider di identità per Microsoft Entra ID e Google.

Ecco un semplice collegamento di disconnessione in una pagina Web:

<a href="/.auth/logout">Sign out</a>

Per impostazione predefinita, una disconnessione riuscita reindirizza il client all'URL /.auth/logout/done. È possibile cambiare la pagina di reindirizzamento post-connessione aggiungendo il parametro di query post_logout_redirect_uri. Ad esempio:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Assicurarsi di codificare il valore di post_logout_redirect_uri.

L'URL deve essere ospitato nello stesso dominio quando si usano URL completi.

Accedere alle attestazioni utente nel codice dell'applicazione

Per tutti i framework del linguaggio, App contenitore rende disponibili le attestazioni nel token in ingresso per il codice dell'applicazione. Le attestazioni vengono inserite nelle intestazioni della richiesta, che sono presenti sia da un utente finale autenticato che da un'applicazione client. Le richieste esterne non sono autorizzate a impostare queste intestazioni, quindi sono presenti solo se impostate da App contenitore. Ecco alcune intestazioni di esempio:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

Il codice scritto in qualsiasi linguaggio o framework può ottenere le informazioni necessarie da queste intestazioni.

Nota

Framework di linguaggio diversi possono presentare queste intestazioni al codice dell'app in formati diversi, ad esempio lettere minuscole o maiuscole.

Passaggi successivi

Per informazioni dettagliate sulla protezione dell'app contenitore, vedere gli articoli seguenti.