Personalizzare l'accesso e la disconnessa nell'autenticazione del servizio app Azure

  • Articolo

Questo articolo illustra come personalizzare gli accessi e le disconnessazioni degli utenti durante l'uso dell'autenticazione e dell'autorizzazione predefiniti in servizio app.

Usare più provider di accesso

La configurazione del portale non offre una soluzione pronta all'uso per presentare agli utenti più provider di accesso, ad esempio tramite Facebook e Twitter. È 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/twitter">Log in with Twitter</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 accede all'utente al provider di identità usando un SDK specifico del provider. Il codice dell'applicazione invia quindi il token di autenticazione risultante a 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 id_tokenproprietà , refresh_tokene expires_in sono facoltative.
microsoftaccount {"access_token":"<access_token>"} oppure {"authentication_token": "<token>" authentication_token è preferibile rispetto access_tokena . 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, verrà aggiunto un token di accesso e un token di aggiornamento all'archivio token. Se specificato, authorization_code può anche essere accompagnato facoltativamente da 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 servizio app non supporta l'accesso personalizzato e la disconnessa.

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://<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 ID e Google, esegue una disconnessa 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"

Limitare il dominio degli account di accesso

Sia l'account Microsoft che l'ID 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 ID 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.comnella parte superiore della pagina selezionare Lettura/Scrittura.

  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 loginParameters matrice con un domain_hint elemento.

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

  5. Fare clic su Put.

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

Importante

È possibile che il client rimuovono il domain_hint parametro 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 negare agli utenti

Anche se 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 con granularità più fine, ad esempio limitando l'accesso solo 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, 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 servizio app passare a site/wwwroot. Se un file Web.config non esiste, crearlo selezionando+> Nuovo file.

  3. Selezionare la matita per Web.config per modificarla. Aggiungere il codice di configurazione seguente e fare clic su Salva. Se Web.config esiste già, è sufficiente aggiungere l'elemento <authorization> con tutti gli elementi in esso contenuti. Aggiungere gli account che si desidera 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 del provider di identità

Il provider di identità può fornire un'autorizzazione di turn-key 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