Condividi tramite

Personalizzare gli accessi e le disconnettezioni nell'autenticazione del servizio app di Azure

Questo articolo illustra come personalizzare gli accessi utente e le disconnessazioni durante l'uso dell'autenticazione e dell'autorizzazione predefiniti nel servizio app di Azure.

Utilizzare più fornitori di accesso

La configurazione del portale di Azure non offre un modo chiavi in mano per presentare più provider di accesso agli utenti. Ad esempio, potresti voler offrire sia Facebook che X come opzioni. Per aggiungere più provider di accesso all'app:

  1. Nell'app Web del portale di Azure selezionare Impostazioni>Autenticazione.

  2. Per Impostazioni di autenticazione selezionare Modifica.

  3. Per Limita l'accesso selezionare Consenti l'accesso non autenticato.

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

    <a href="/.auth/login/aad">Log in with Microsoft Entra</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>
<a href="/.auth/login/apple">Log in with Apple</a>

Quando l'utente seleziona uno dei collegamenti, viene aperta la rispettiva pagina per l'accesso.

Per reindirizzare l'utente a un URL personalizzato dopo l'accesso, usare il parametro della post_login_redirect_uri stringa di query. Ad esempio, per spostare l'utente in /Home/Index dopo l'accesso, usare il codice HTML seguente:

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

Nota

Non confondere questo valore con l'URI di reindirizzamento nella configurazione del provider di identità.

Usare l'accesso diretto dal cliente

In un accesso guidato dal client, l'applicazione effettua l'accesso dell'utente presso il provider di identità usando un SDK specifico del provider. Il codice dell'applicazione invia quindi il token di autenticazione risultante al servizio app per la convalida usando una richiesta HTTP POST . Questa convalida stessa non concede agli utenti l'accesso alle risorse dell'app desiderate. Una convalida riuscita offre agli utenti un token di sessione che possono usare per accedere alle risorse dell'app. Per altre informazioni, vedere Flusso di autenticazione.

Per convalidare il token del provider, l'app del servizio app 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://<appname>.azurewebsites.net/.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:

Valore del fornitore Obbligatorio nel corpo della richiesta Commenti
aad {"access_token":"<access_token>"} Le proprietà id_token, refresh_token e expires_in sono facoltative.
google {"id_token":"<id_token>"} La proprietà authorization_code è facoltativa. Se si specifica un valore authorization_code, si aggiungono un token di accesso e un token di aggiornamento all'archivio token. Quando si specifica authorization_code, è possibile associarlo facoltativamente a una redirect_uri proprietà .
facebook {"access_token":"<user_access_token>"} Usare un token di accesso valido dell'utente da Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Nota

Il provider GitHub per l'autenticazione di App Service non supporta l'accesso e la disconnessione personalizzati.

Se il token del provider viene convalidato correttamente, l'API restituisce un authenticationToken valore nel corpo della risposta. Questo valore è il token di sessione. Per altre informazioni sulle attestazioni utente, vedere Usare le identità utente nell'autenticazione del servizio app di Azure.

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

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

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Disconnettersi da una sessione

Gli utenti possono avviare una disconnessione inviando una richiesta GET all'endpoint /.auth/logout dell'app. Richiesta GET:

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

Ecco un semplice collegamento di disconnessione in una pagina Web:

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

Per impostazione predefinita, una corretta disconnessione reindirizza il client all'URL /.auth/logout/complete. È 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

È consigliabile codificare il valore di post_logout_redirect_uri.

Quando si usano URL completamente qualificati, l'URL deve essere ospitato nello stesso dominio o configurato come URL di reindirizzamento esterno consentito per l'app. Nell'esempio seguente viene eseguito il reindirizzamento a un https://myexternalurl.com URL non ospitato nello stesso dominio:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Eseguire il comando seguente in Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Mantenere i frammenti di URL

Dopo che gli utenti hanno eseguito l'accesso all'app, di solito vogliono essere reindirizzati alla stessa sezione della stessa pagina, ad esempio /wiki/Main_Page#SectionZ. Tuttavia, poiché i frammenti di URL, ad esempio #SectionZ, non vengono mai inviati al server, non sono mantenuti per impostazione predefinita dopo che l'accesso OAuth viene completato e ritorna all'app. Gli utenti ottengono quindi un'esperienza non ottimale quando devono passare di nuovo all'ancoraggio desiderato. Questa limitazione si applica a tutte le soluzioni di autenticazione lato server.

Nell'autenticazione del servizio app è possibile mantenere i frammenti di URL nell'accesso OAuth impostando WEBSITE_AUTH_PRESERVE_URL_FRAGMENT su true. Usare questa impostazione dell'app nel portale di Azure oppure eseguire il comando seguente in Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Impostare l'hint di dominio per gli account di accesso

Sia gli account Microsoft che Microsoft Entra consentono agli utenti di accedere da più domini. Ad esempio, un account Microsoft consente gli account outlook.com, live.com e hotmail.com. Microsoft Entra consente un numero qualsiasi di domini personalizzati per gli account di accesso. Tuttavia, è possibile indirizzare rapidamente gli utenti direttamente alla pagina di accesso di Microsoft Entra personalizzata (ad esempio contoso.com).

Per suggerire il nome di dominio degli account di accesso, seguire questa procedura:

  1. In Esplora risorse selezionare Lettura/Scrittura nella parte superiore della pagina.

  2. Nel riquadro sinistro, vai a subscriptions>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2.

  3. Seleziona Modifica

  4. Aggiungere una loginParameters matrice con un domain_hint elemento:

    "identityProviders": {
    "azureActiveDirectory": {
        "login": {
            "loginParameters": ["domain_hint=<domain-name>"],
        }
    }
}

  5. Selezionare Put.

Questa impostazione aggiunge il parametro della domain_hint stringa di query all'URL di reindirizzamento di accesso.

Importante

È possibile che il client rimuova il parametro domain_hint dopo aver ricevuto l'URL di reindirizzamento e quindi accedere a un dominio diverso. Quindi, anche se questa funzione è comoda, non è una funzionalità di sicurezza.

Autorizzare o rifiutare gli utenti

Il servizio app si occupa del caso di autorizzazione più semplice, ad esempio rifiuta le richieste non autenticate. L'app potrebbe richiedere un comportamento di autorizzazione più granulare, ad esempio limitare l'accesso solo a un gruppo specifico di utenti.

Potrebbe essere necessario scrivere codice applicazione personalizzato per consentire o negare l'accesso all'utente connesso. In alcuni casi, il servizio app o il provider di identità potrebbe essere utile senza che siano necessarie modifiche al codice.

Livello server (solo app di Windows)

Per qualsiasi app di Windows, è possibile definire il comportamento di autorizzazione del server Web IIS modificando il web.config file. Le app Linux non usano IIS e non possono essere configurate tramite web.config.

  1. Per passare alla console di debug Kudu per l'app, selezionare Strumenti> di sviluppoStrumenti avanzati e selezionare Vai. Selezionare quindi Console di debug.

    È anche possibile aprire questa pagina con questo URL: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole. Per ottenere i valori di hash e area casuali, nella Panoramica della tua app copia Dominio predefinito.

  2. Nello strumento di esplorazione dei file del servizio app, passare a site/wwwroot. Se web.config non esiste, crearlo selezionando +>Nuovo file.

  3. Selezionare la matita accanto a web.config per modificare il file. Aggiungere il codice di configurazione seguente e quindi selezionare Salva. Se web.config esiste già, è sufficiente aggiungere l'elemento <authorization> con tutto il contenuto. Nell'elemento <allow> aggiungere gli account che si desidera consentire.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="[email protected],[email protected]"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Livello provider di identità

Il provider di identità potrebbe fornire determinate autorizzazioni chiavi in mano. Ad esempio:

Livello applicazione

Se uno degli altri livelli non fornisce l'autorizzazione necessaria o se la piattaforma o il provider di identità non è supportato, è necessario scrivere codice personalizzato per autorizzare gli utenti in base alle attestazioni utente.

Contenuti correlati