Personalizzare l'accesso e la disconnessione nell'autenticazione del Servizio app di Azure

  • Articolo

Questo articolo illustra come personalizzare gli accessi e le disconnessazioni utente durante l'uso di autenticazione e autorizzazione predefinite nel Servizio app.

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 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 fa clic su uno dei collegamenti, viene aperta la pagina di accesso corrispondente per l'accesso dell'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 al Servizio app per la convalida (vedere Flusso di autenticazione) usando una richiesta HTTP POST. La convalida non garantisce effettivamente l'accesso alle risorse dell'app desiderate, ma il completamento della convalida fornisce un token di sessione da usare per accedere alle risorse dell'app.

Per convalidare il token del provider, l'app del servizio app deve essere innanzitutto 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. 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 valore authorization_code, un token di accesso e un token di aggiornamento verranno aggiunti 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":"<access_token_secret>"}

Nota

Il provider GitHub per l'autenticazione del Servizio app non supporta l'accesso e la disconnessione personalizzati.

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

{
    "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://<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. La richiesta GET esegue le operazioni seguenti:

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

Ecco un semplice collegamento per la 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 per eseguire il reindirizzamento a https://myexternalurl.com che 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 si completa e ritorna all'app. Gli utenti otterranno un'esperienza ottimale quando dovranno tornare di nuovo al segnalibro. Questa limitazione si applica a tutte le soluzioni di autenticazione lato server.

Nell'autenticazione del servizio app è possibile mantenere i frammenti di URL durante l'accesso OAuth. Per farlo è necessario configurare l'impostazione app WEBSITE_AUTH_PRESERVE_URL_FRAGMENT su true. Si procede dal portale di Azure o semplicemente eseguendo il comando seguente in Azure Cloud Shell:

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

Impostazione dell'hint di dominio per gli account di accesso

Sia l'account Microsoft che Microsoft Entra consentono di accedere da più domini. L'account Microsoft consente, ad esempio, 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 accelerare 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 https://resources.azure.com selezionare Lettura/Scrittura nella parte superiore della pagina.

  2. Nel browser a sinistra passare a subscriptions><subscription-name>resourceGroups><resource-group-name>>providers>Microsoft.Web>sites><app-name>>config>authsettingsV2.

  3. Fare clic su Modifica.

  4. Aggiungere una matrice loginParameters con un elemento domain_hint.

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

  5. Fare clic su Put.

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

Importante

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

Autorizzare o rifiutare gli utenti

Anche se il Servizio app si occupa del caso di autorizzazione più semplice, ad esempio rifiutare le richieste non autenticate, l'app potrebbe richiedere un comportamento di autorizzazione più granulare, ad esempio limitando l'accesso a un gruppo specifico di utenti. In alcuni casi è necessario scrivere codice applicazione personalizzato per consentire o negare l'accesso all'utente connesso. In altri casi, il Servizio app o il provider di identità può essere utile senza richiedere 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 file Web.config. Le app Linux non usano IIS e non possono essere configurate tramite Web.config.

  1. Passare a https://<app-name>.scm.azurewebsites.net/DebugConsole

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

  3. Selezionare la matita per Web.config per modificarlo. Aggiungere il codice di configurazione seguente e fare clic su Salva. Se Web.config esiste già, è sufficiente aggiungere l'elemento <authorization> con tutto il contenuto. Aggiungere gli account da consentire nell'elemento <allow>.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="user1@contoso.com,user2@contoso.com"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Livello provider di identità

Il provider di identità può fornire un'autorizzazione chiavi in mano specifica. 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.

Altre risorse