Condividi tramite


Usare Frontdoor di Azure come proxy inverso nell'ambiente di produzione per un'app a pagina singola che usa l'autenticazione nativa (anteprima)

Si applica a: cerchio verde con un segno di spunta bianco che indica che il contenuto seguente si applica ai tenant esterni. Tenant esterni (altre informazioni)

Questo articolo illustra come usare Frontdoor di Azure come proxy inverso per un'app a pagina singola che usa 'API di autenticazione nativa.

L'API di autenticazione nativa non supporta la condivisione di risorse tra le origini (CORS). Pertanto, un'applicazione a pagina singola (SPA) che utilizza questa API per l'autenticazione dell'utente non può inviare con successo richieste dal codice JavaScript del "front-end". Per risolvere questo problema, aggiungere un server proxy tra la SPA e l'API di autenticazione nativa. Il server proxy inserisce le intestazioni CORS appropriate nella risposta.

In un ambiente di produzione, è consigliabile usare Azure Front Door con una sottoscrizione Standard/Premium come reverse proxy.

Prerequisiti

Configurare Frontdoor di Azure come proxy inverso

  1. Acquisire familiarità con l'uso di Frontdoor di Azure con CORS leggendo l'articolo uso di Frontdoor di Azure Standard/Premium con CORS.
  2. Usare le istruzioni in Abilitare domini URL personalizzati per le app in tenant esterni per aggiungere un nome di dominio personalizzato al tenant esterno.
  3. Nella SPA di esempio, aprire il file API\React\ReactAuthSimple\src\config.ts, quindi sostituire i valori di BASE_API_URLe http://localhost:3001/apicon https://Enter_Custom_Domain_URL/Enter_the_Tenant_ID_Here. Sostituire il segnaposto:
    1. Enter_Custom_Domain_URL con l'URL del dominio personalizzato, ad esempio contoso.com.
    2. Enter_the_Tenant_ID_Here con il tuo ID Directory (tenant). Se non hai l'ID del tenant, scopri come leggere i dettagli del tenant.
  4. Se necessario, riavviare l'app SPA di esempio.

Creare Azure Front Door come un proxy inverso usando un modello di Azure Developer CLI (azd)

  1. Per inizializzare il modello azd, eseguire il comando seguente:

    azd init --template https://github.com/azure-samples/ms-identity-extid-cors-proxy-frontdoor
    

    Quando richiesto, immettere un nome per l'ambiente azd. Il nome viene usato come prefisso per il gruppo di risorse in modo che sia univoco all'interno della sottoscrizione di Azure.

  2. Per accedere ad Azure, eseguire il comando seguente:

    azd auth login
    
  3. Per compilare, effettuare il provisioning e distribuire le risorse dell'app, eseguire il comando seguente:

    azd up
    

    Quando richiesto, immettere le informazioni seguenti per completare la creazione delle risorse:

    • Azure Location: La posizione di Azure in cui sono distribuite le risorse.
    • Azure Subscription: sottoscrizione di Azure in cui vengono distribuite le risorse.
    • corsAllowedOrigin: dominio di origine per consentire le richieste CORS da nel formato SCHEME://DOMAIN:PORT, ad esempio http://localhost:3000.
    • tenantSubdomain: il sottodominio del vostro tenant esterno che stiamo proxyando. Ad esempio, se il dominio primario del tenant è contoso.onmicrosoft.com, usare contoso. Se non hai il sottodominio del tuo tenant, scopri come leggere i dettagli del tuo tenant.
    • customDomain: URL completo del dominio personalizzato configurato all'interno dell'ID esterno, ad esempio login.example.com.

Linee guida per l'uso di Frontdoor di Azure come proxy inverso

Quando si configura Frontdoor di Azure come proxy inverso per gestire le intestazioni CORS in un ambiente di produzione, è consigliabile seguire le linee guida seguenti:

Limitare le origini

Quando si configura Azure Front Door, consentire solo l'URL del dominio SPA, https://www.contoso.comad esempio, come origine. Evitare configurazioni che consentano tutte le origini, ad esempio * che potrebbero causare vulnerabilità di sicurezza.

Usare richieste semplici

Le richieste di autenticazione native soddisfano già tutte le condizioni di richieste semplici:

  • Usa Http Method: POST.
  • Usa Content-Type: application/x-www-form-urlencoded.
  • La richiesta non richiede intestazioni personalizzate.
  • La richiesta non coinvolge l'oggetto ReadableStream nella richiesta.
  • La richiesta non richiede l'utilizzo di XMLHttpRequest.