Condividi tramite

Configurare l'app di App Service o di Azure Functions per utilizzare l'accesso di Microsoft Entra

Selezionare un altro provider di autenticazione per passare a tale provider.

Questo articolo illustra come configurare l'autenticazione per il Servizio app di Azure o Funzioni di Azure in modo che l'app consenta l’accesso agli utenti con la piattaforma di identità Microsoft (Microsoft Entra) come provider di autenticazione.

Scegliere un tenant per l'applicazione e i relativi utenti

Prima che l'applicazione possa consentire l'accesso agli utenti, è necessario registrarla in un tenant della forza lavoro o in un tenant esterno. Se si rende disponibile l'app ai dipendenti o agli ospiti aziendali, registrare l'app in un tenant del personale. Se l'app è destinata a utenti e clienti aziendali, registrarla in un tenant esterno.

  1. Accedere al portale di Azure e passare all'app.

  2. Nel menu a sinistra dell'app, selezionare Impostazioni>Autenticazione, quindi selezionare Aggiungi provider di identità.

  3. Nella pagina Aggiungi provider di identità, selezionare Microsoft come valore Provider di identità per accedere alle identità Microsoft e Microsoft Entra.

  4. In Scegliere un tenant per l'applicazione e i relativi utenti selezionare una delle opzioni seguenti:

    • Configurazione del personale (tenant corrente) per i dipendenti e gli ospiti aziendali
    • Configurazione esterna per consumatori e clienti aziendali

Scegliere la registrazione app

La funzionalità di autenticazione del servizio app può creare automaticamente una registrazione dell'app. In alternativa, è possibile usare una registrazione creata separatamente dall'utente o da un amministratore della directory.

Creare automaticamente una nuova registrazione app, a meno che non sia necessario creare una registrazione app separatamente. È possibile personalizzare la registrazione app nell’Interfaccia di amministrazione di Microsoft Entra in un secondo momento.

Le situazioni seguenti sono i casi più comuni per l'uso di una registrazione dell'app esistente:

  • Il tuo account non dispone delle autorizzazioni per creare registrazioni di app nel tenant di Microsoft Entra.
  • Si desidera utilizzare una registrazione dell'app da un tenant Microsoft Entra diverso da quello che ospita la propria app. Questo è sempre il caso se è stata selezionata la configurazione esterna quando si sceglie un tenant.
  • L'opzione per creare una nuova registrazione non è disponibile per i cloud per enti pubblici.

Opzione 1: Creare e usare una nuova registrazione app

  1. Selezionare Crea una nuova registrazione dell'app.

  2. In Nome immettere il nome della nuova registrazione dell'app.

  3. Selezionare il valore Tipo di account supportato :

    • Tenant corrente - Tenant singolo. Account solo in questa directory organizzativa. Tutti gli account di utenti e ospiti nella directory possono utilizzare l'applicazione o l'API. Usare questa opzione se il gruppo di destinatari è interno all'organizzazione.
    • Qualunque directory di Microsoft Entra - Multitenant. Account in qualsiasi directory organizzativa. Tutti gli utenti con un account Microsoft aziendale o dell'istituto di istruzione possono usare l'applicazione o l'API. Questi account includono istituti di istruzione e aziende che usano Office 365. Usare questa opzione se il gruppo di destinatari è costituito da clienti aziendali o di istituti di istruzione e per abilitare il multi-tenancy.
    • Qualunque directory di Microsoft Entra e account di Microsoft personali. Account in qualunque directory organizzativa e account di Microsoft personali (ad esempio Skype o Xbox). Tutti gli utenti con un account aziendale o dell'istituto di istruzione o con un account Microsoft personale possono usare l'applicazione o l'API. Include istituti di istruzione e aziende che usano Office 365, insieme agli account personali usati per accedere a servizi come Xbox e Skype. Usare questa opzione per includere il set più ampio possibile di identità Microsoft e per abilitare la multi-tenancy.
    • Solo account di Microsoft personali. Account personali usati per accedere a servizi quali Xbox e Skype. Usare questa opzione per includere il set più ampio possibile di identità Microsoft.

È possibile modificare il nome della registrazione o i tipi di account supportati in un secondo momento.

Un segreto client viene creato come impostazione dell’applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Se si vuole gestire il segreto in Azure Key Vault, è possibile aggiornare tale impostazione in un secondo momento per usare i riferimenti a Key Vault. In alternativa, è possibile modificare questa impostazione in modo da usare un'identità anziché un segreto client. Il supporto per l'uso di un'identità è attualmente in modalità anteprima.

Opzione 2: Usare una registrazione esistente creata separatamente

Per usare una registrazione esistente, selezionare una delle seguenti operazioni:

  • Scegliere una registrazione app esistente in questa directory. Selezionare quindi una registrazione dell'app dall'elenco a discesa.

  • Specificare i dettagli di una registrazione dell'app esistente. Specificare quindi:

    • ID applicazione (client).

    • Segreto del cliente (consigliato). Valore segreto usato dall'applicazione per dimostrare la propria identità quando richiede un token. Questo valore viene salvato nella configurazione dell'app come impostazione dell'applicazione slot-sticky denominata MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Se il segreto client non è impostato, le operazioni di accesso dal servizio usano il flusso di concessione implicita OAuth 2.0, che non raccomandiamo.

      È anche possibile configurare l'applicazione per l'uso di un'identità anziché di un segreto client. Il supporto per l'uso di un'identità è attualmente in modalità anteprima.

    • URL dell'emittente. Questo URL ha il formato <authentication-endpoint>/<tenant-id>/v2.0. Sostituire <authentication-endpoint> con il valore dell'endpoint di autenticazione specifico dell'ambiente cloud. Ad esempio, un tenant della forza lavoro in Azure globale userà https://sts.windows.net come endpoint di autenticazione.

Se è necessario creare manualmente una registrazione dell'app in un tenant della forza lavoro, vedere Registrare un'applicazione con Microsoft Identity Platform. Durante il processo di registrazione, prendere nota dei valori di ID applicazione (client) e segreto client.

Durante il processo di registrazione, nella sezione URI di reindirizzamento selezionare Web per piattaforma e immettere un URI di reindirizzamento. Ad esempio, immettere https://contoso.azurewebsites.net/.auth/login/aad/callback.

Modificare ora la registrazione dell'app:

  1. Nel riquadro sinistro, selezionare Esporre un'API>Aggiungi>Salva. Questo valore identifica in modo univoco l'applicazione quando viene usata come risorsa, che consente la richiesta di token che concedono l'accesso. Il valore è un prefisso per gli ambiti creati.

    Per un'app a singolo tenant è possibile usare il valore predefinito, nel formato api://<application-client-id>. È anche possibile specificare un URI più leggibile come https://contoso.com/api, in base a uno dei domini verificati per il tenant. Per un'app multitenant è necessario fornire un URI personalizzato. Per ulteriori informazioni sui formati accettati degli URI degli ID delle app, vedere le procedure consigliate per la sicurezza delle proprietà dell'applicazione in Microsoft Entra ID.

  2. Selezionare Aggiungi un ambito e quindi:

    1. In Nome ambito, immettere user_impersonation.
    2. In Chi può fornire il consenso, selezionare Amministratori e utenti se si desidera consentire agli utenti di fornire il consenso a questo ambito.
    3. Immettere il nome dell'ambito di consenso. Immettere una descrizione che si vuole che gli utenti visualizzino nella pagina di consenso. Ad esempio, immettere Accessapplication-name.
    4. Seleziona Aggiungi ambito.

  3. (Scelta consigliata) Creare un'asserzione client per l'app. Per creare un segreto del client:

    1. Nel riquadro sinistro selezionare Certificati e segreti>Segreti client>Nuovo segreto client.
    2. Immettere una descrizione e una scadenza e quindi selezionare Aggiungi.
    3. Copiare il valore del segreto client nel campo Valore. Dopo che ti allontani da questa pagina, non verrà più visualizzata.

    È anche possibile configurare l'applicazione per l'uso di un'identità anziché di un segreto client. Il supporto per l'uso di un'identità è attualmente in modalità anteprima.

  4. (Facoltativo) Per aggiungere più URL di risposta, selezionare Autenticazione.

Configurare controlli aggiuntivi

Controlli aggiuntivi determinano quali richieste sono autorizzate ad accedere all'applicazione. È ora possibile personalizzare questo comportamento oppure modificare queste impostazioni in un secondo momento dalla pagina Principale di autenticazione selezionando Modifica accanto a Impostazioni di autenticazione.

Per Requisiti dell'applicazione client, scegliere se:

  • Consenti richieste solo da questa applicazione.
  • Consenti richieste da applicazioni client specifiche.
  • Consenti richieste da qualsiasi applicazione (scelta non consigliata).

Per Requisito identità, scegliere se:

  • Consentire richieste da qualunque identità.
  • Consentire richieste da identità specifiche.

Per Requisito tenant, scegliere se:

  • Consentire richieste solo dal tenant emittente.
  • Consentire richieste da tenant specifici.
  • Usare le restrizioni predefinite in base all'autorità emittente.

L'app potrebbe comunque dover prendere altre decisioni di autorizzazione nel codice. Per altre informazioni, vedere Usare un criterio di autorizzazione predefinito più avanti in questo articolo.

Configurare impostazioni di autenticazione

Le impostazioni di autenticazione determinano il modo in cui l'applicazione risponde alle richieste non autenticate. Le selezioni predefinite reindirizzano tutte le richieste di accesso con questo nuovo provider. È ora possibile personalizzare questo comportamento oppure modificare queste impostazioni in un secondo momento dalla pagina Principale di autenticazione selezionando Modifica accanto a Impostazioni di autenticazione. Per altre informazioni, vedere Flusso di autenticazione.

Per Limita l'accesso, decidere se:

  • Richiedere l'autenticazione.
  • Consentire l'accesso non autenticato.

Per le richieste non autenticate, scegliere le opzioni di errore:

  • HTTP 302 Found redirect: consigliato per i siti Web
  • HTTP 401 Unauthorized: consigliato per le API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Selezionare Archivio token (scelta consigliata). L'archivio token raccoglie, archivia e aggiorna i token per l'applicazione. È possibile disabilitare questo comportamento in un secondo momento se l'app non richiede token o se è necessario ottimizzare le prestazioni.

Aggiungere il fornitore di identità

Se è stata selezionata la configurazione della forza lavoro, è possibile selezionare Avanti: Autorizzazioni e aggiungere le autorizzazioni di Microsoft Graph necessarie all'applicazione. Queste autorizzazioni vengono aggiunte alla registrazione dell'app, ma è anche possibile modificarle in un secondo momento. Se è stata selezionata la configurazione esterna, è possibile aggiungere le autorizzazioni di Microsoft Graph in un secondo momento.

  • Selezionare Aggiungi.

A questo punto, è possibile usare Microsoft Identity Platform per l'autenticazione nell'app. Il provider è elencato nella pagina Autenticazione . Da qui è possibile modificare o eliminare questa configurazione del provider.

Per un esempio di configurazione dell'accesso di Microsoft Entra per una web app che accede ad Azure Storage e Microsoft Graph, vedere Aggiungere l'autenticazione a un'app web.

Autorizzare le richieste

Per impostazione predefinita, l'autenticazione di Servizio app gestisce solo l'autenticazione. Determina se il chiamante è chi dice di essere. L'autorizzazione, determinando se il chiamante deve avere accesso a una risorsa, è un passaggio oltre l'autenticazione. Per altre informazioni, vedere Nozioni di base sull'autorizzazione.

L'app può prendere decisioni di autorizzazione nel codice. L'autenticazione del servizio app fornisce alcuni controlli predefiniti, che possono essere utili, ma potrebbero non essere sufficienti per soddisfare le esigenze di autorizzazione dell'app. Le sezioni seguenti illustrano queste funzionalità.

Suggerimento

Le applicazioni multi-tenant devono convalidare l'emittente e l'ID tenant della richiesta come parte di questo processo per assicurarsi che i valori siano consentiti. Quando l'autenticazione del servizio app è configurata per uno scenario multi-tenant, non convalida il tenant da cui proviene la richiesta. Potrebbe essere necessario limitare un'app a tenant specifici, a seconda che l'organizzazione abbia effettuato o meno l'iscrizione al servizio, ad esempio. Consulta Aggiorna il codice per gestire più valori del soggetto emittente.

Eseguire convalide dal codice dell'applicazione

Quando si eseguono controlli di autorizzazione nel codice dell'app, è possibile usare le informazioni sulle attestazioni resi disponibili dall'autenticazione del servizio app. Per altre informazioni, vedere Accedere alle attestazioni utente nel codice dell'app.

L'intestazione x-ms-client-principal inserita contiene un oggetto JSON con codifica Base64 con le attestazioni asserite sul chiamante. Per impostazione predefinita, queste attestazioni passano attraverso un mapping delle attestazioni, quindi i nomi delle attestazioni potrebbero non corrispondere sempre a quello visualizzato nel token. Ad esempio, l'attestazione tid viene mappata a http://schemas.microsoft.com/identity/claims/tenantid.

È anche possibile usare direttamente il token di accesso sottostante dall'intestazione x-ms-token-aad-access-token inserita.

Usare criteri di autorizzazione predefiniti

La registrazione dell'app creata autentica le richieste in ingresso per il tenant di Microsoft Entra. Per impostazione predefinita, consente anche a chiunque all'interno del tenant di accedere all'applicazione. Questo approccio è adatto a molte applicazioni. Alcune applicazioni devono limitare ulteriormente l'accesso prendendo decisioni di autorizzazione.

Il codice dell'applicazione è spesso la posizione migliore per gestire la logica di autorizzazione personalizzata. Per scenari comuni, tuttavia, Microsoft Identity Platform fornisce controlli predefiniti che è possibile usare per limitare l'accesso.

Questa sezione illustra come abilitare i controlli predefiniti usando l'API di autenticazione del servizio app V2. Attualmente, l'unico modo per configurare questi controlli predefiniti consiste nell'usare i modelli di Azure Resource Manager o l'API REST.

All'interno dell'oggetto API, la configurazione del provider di identità Microsoft Entra include una validation sezione che può includere un defaultAuthorizationPolicy oggetto, come illustrato nella struttura seguente:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Proprietà Descrizione
defaultAuthorizationPolicy Un gruppo di requisiti che devono essere soddisfatti per l'accesso all'app. L'accesso viene concesso in base a un AND logico su ognuna delle proprietà configurate. Quando allowedApplications e allowedPrincipals sono configurati entrambi, la richiesta in ingresso deve soddisfare entrambi i requisiti da accettare.
allowedApplications Un elenco elementi consentiti di ID client dell'applicazione stringa che rappresentano la risorsa client che chiama nell'app. Quando questa proprietà è configurata come matrice non vuoto, vengono accettati solo i token ottenuti da un'applicazione specificata nell'elenco.

Questo criterio valuta la rivendicazione appid o azp del token in ingresso, che deve essere un token di accesso. Vedere Attestazioni di payload.
allowedPrincipals Un gruppo di controlli che determinano se l'entità che la richiesta in ingresso rappresenta può accedere all'app. La soddisfazione di allowedPrincipals si basa su un OR logico per le proprietà configurate.
identities (in allowedPrincipals) Un elenco elementi consentiti di ID oggetto stringa che rappresentano utenti o applicazioni a cui è consentito l'accesso. Quando questa proprietà è configurata come matrice non vuota, il requisito può essere soddisfatto se l'utente o l'applicazione che la richiesta rappresenta è specificato nell'elenco. È previsto un limite di 500 caratteri (totale) nell'elenco delle identità.

Questo criterio valuta l'attestazione oid del token in ingresso. Vedere Attestazioni di payload.

È anche possibile configurare alcuni controlli tramite un'impostazione dell'applicazione, indipendentemente dalla versione dell'API in uso. È possibile configurare l'impostazione dell'applicazione WEBSITE_AUTH_AAD_ALLOWED_TENANTS con un elenco delimitato da virgole di un massimo di 10 ID tenant, aaaabbbb-0000-cccc-1111-dddd2222eeeead esempio . Questa impostazione può richiedere che il token in ingresso proveni da uno dei tenant specificati, come specificato dall'attestazione tid .

È possibile configurare l'impostazione dell'applicazione WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL su true o 1per richiedere al token in ingresso di includere un'attestazione oid . Se è stato configurato allowedPrincipals.identities, questa impostazione viene ignorata e considerata true poiché l'attestazione oid viene verificata in base all'elenco di identità fornito.

Le richieste che non soddisfano questi controlli predefiniti ottengono una risposta HTTP 403 Forbidden .

Usare un'identità gestita anziché un segreto (anteprima)

Anziché configurare un segreto client per la registrazione dell'app, è possibile configurare un'applicazione in modo che consideri attendibile un'identità gestita (anteprima). L'uso di un'identità invece di un segreto significa che non è necessario gestire un segreto. Non si dispone di eventi di scadenza dei segreti da gestire e non si ha lo stesso livello di rischio associato alla possibile divulgazione o perdita di tale segreto.

L'identità consente di creare una credenziale di identità federata, che può essere usata al posto di un segreto client come asserzione client. Questo approccio è disponibile solo per le configurazioni della forza lavoro. La funzionalità di autenticazione predefinita supporta attualmente le credenziali di identità federate come anteprima.

È possibile usare i passaggi descritti in questa sezione per configurare il servizio app o la risorsa di Funzioni di Azure per usare questo modello. I passaggi descritti presuppongono che sia già stata configurata una registrazione dell'app usando uno dei metodi supportati e che sia già definito un segreto.

  1. Seguire queste istruzioni per creare una risorsa identità gestita assegnata dall'utente.

  2. Assegna tale identità alla risorsa di App Service o di Azure Functions.

    Importante

    L'identità gestita assegnata dall'utente che crei deve essere assegnata solo al servizio app o all'applicazione Funzioni di Azure tramite questa registrazione. Se si assegna l'identità a un'altra risorsa, si concede a tale risorsa l'accesso non necessario alla registrazione dell'app.

  3. Prendere nota dei valori ID oggetto e ID client dell'identità gestita. Sarà necessario l'ID oggetto per creare una credenziale di identità federata nel passaggio successivo. L'ID client dell'identità gestita verrà usato in un passaggio successivo.

  4. Seguire le istruzioni di Microsoft Entra ID per configurare una credenziale di identità federata in un'applicazione esistente. Queste istruzioni includono anche sezioni per l'aggiornamento del codice dell'applicazione, che è possibile ignorare.

  5. Aggiungere una nuova impostazione dell'applicazione denominataOVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Imposta il suo valore al valore dell'ID client dell'identità gestita ottenuto in un passaggio precedente. Non usare l'ID client della registrazione della tua app. Assicurarsi di contrassegnare questa impostazione dell'applicazione come slot-sticky.

  6. Nelle impostazioni di autenticazione predefinite per la risorsa dell'app, impostare nome dell'impostazione del segreto del client su OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Per apportare questa modifica tramite il portale di Azure:

    1. Tornare alla risorsa Servizio app o Funzioni di Azure e selezionare la scheda Autenticazione .
    2. Nella sezione Provider di identità, per la voce Microsoft, selezionare l'icona nella colonna Modifica.
    3. Nella finestra di dialogo Modifica provider di identità, aprire l'elenco a discesa per Nome impostazione segreto client e selezionare OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Seleziona Salva.

    Per apportare questa modifica usando l'API REST:

    • Impostare la proprietà clientSecretSettingName su OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Questa proprietà è disponibile in properties>identityProviders>azureActiveDirectory>registration.

  7. Verificare che l'applicazione funzioni come previsto. Dovrebbe essere possibile eseguire correttamente una nuova azione di accesso.

Quando si è soddisfatti del funzionamento usando un'identità gestita, rimuovere il segreto esistente:

  1. Assicurarsi che il codice dell'app non assuma una dipendenza dall'impostazione dell'applicazione. In caso affermativo, seguire le istruzioni per aggiornare il codice dell'applicazione per richiedere un token di accesso.

  2. Rimuovere l'impostazione dell'applicazione che in precedenza ha mantenuto il segreto. Il nome di questa impostazione dell'applicazione corrisponde al valore precedente del nome dell'impostazione del segreto client, prima di modificarlo in OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Accedere all'interfaccia di amministrazione di Microsoft Entra usando il tenant che contiene la registrazione dell'app. Passare di nuovo alla registrazione dell'app.

  4. In Certificati e segreti selezionare Segreti client e rimuovere il segreto client.

L'app è ora configurata per l'uso dell'autenticazione di Microsoft Entra ID senza segreti.

Configurare le app client per accedere al servizio app

Nelle sezioni precedenti, hai registrato la tua app di App Service o Funzioni di Azure per autenticare gli utenti. Le sezioni seguenti illustrano come registrare client nativi o app daemon in Microsoft Entra. Questi client o app possono richiedere l'accesso alle API esposte dal servizio app per conto di utenti o utenti stessi, ad esempio in un'architettura a più livelli. Se si vuole solo autenticare gli utenti, i passaggi descritti nelle sezioni seguenti non sono necessari.

Applicazione client nativa

È possibile registrare client nativi per richiedere l'accesso alle API dell'app del servizio app per conto di un utente connesso:

  1. Nel menu del portale di Azure selezionare Microsoft Entra ID.

  2. Nel riquadro sinistro selezionare Gestisci>registrazioni app. Selezionare quindi Nuova registrazione.

  3. Nel riquadro Registra un'applicazione immettere un nome per la registrazione dell'app in Nome.

  4. In URI di reindirizzamento selezionare Client pubblico/nativo (mobile e desktop) e immettere l'URL di reindirizzamento. Ad esempio, immettere https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selezionare Registra.

  6. Dopo la creazione della registrazione dell'app, copiare il valore di ID applicazione (client).

    Nota

    Per un'applicazione di Microsoft Store, usare invece il SID pacchetto come URI.

  7. Nel riquadro sinistro selezionare Gestisci>autorizzazioni API. Quindi selezionare Aggiungi un'autorizzazione>My APIs.

  8. Selezionare la registrazione creata in precedenza per l'app di Servizio app. Se la registrazione dell'app non è visibile, accertarsi di aver aggiunto l'ambito user_impersonation nella registrazione dell'app.

  9. Selezionare user_impersonation in Autorizzazioni delegate, quindi selezionare Aggiungi autorizzazioni.

A questo punto è stata configurata un'applicazione client nativa in grado di richiedere l'accesso all'app del servizio app per conto di un utente.

Applicazione client daemon (chiamate da servizio a servizio)

In un'architettura a più livelli, l'applicazione client può acquisire un token per chiamare un servizio app o un'app di Funzioni di Azure per conto dell'app client stessa, non per conto di un utente. Questo scenario è utile per le applicazioni daemon non interattive che eseguono attività senza un utente connesso. Usa la concessione di credenziali client OAuth 2.0 standard. Per altre informazioni, vedere Microsoft Identity Platform e il flusso delle credenziali client OAuth 2.0.

  1. Nel menu del portale di Azure selezionare Microsoft Entra ID.

  2. Nel riquadro sinistro selezionare Gestisci>registrazioni app. Selezionare quindi Nuova registrazione.

  3. Nel riquadro Registra un'applicazione immettere un nome per la registrazione dell'app in Nome.

  4. Per un'applicazione daemon, non è necessario un URI di reindirizzamento, quindi è possibile mantenere vuota la casella URI di reindirizzamento .

  5. Selezionare Registra.

  6. Dopo la creazione della registrazione dell'app, copiare il valore di ID applicazione (client).

  7. Nel riquadro sinistro selezionare Gestisci>certificati e segreti. Seleziona Segreti client>Nuovo segreto del client.

  8. Immettere una descrizione e una scadenza e quindi selezionare Aggiungi.

  9. Copiare il valore del segreto client nel campo Valore. Dopo che ti allontani da questa pagina, non verrà più visualizzata.

È ora possibile richiedere un token di accesso usando l'ID client e il segreto client. Impostare il resource parametro sul valore URI ID applicazione dell'app di destinazione. Il token di accesso risultante può quindi essere presentato all'app di destinazione tramite l'intestazione di autorizzazione OAuth 2.0 standard. L'autenticazione del servizio app convalida e usa il token per indicare che il chiamante è autenticato. In questo caso, il chiamante è un'applicazione, non un utente.

Questo approccio consente a qualsiasi applicazione client nel tenant di Microsoft Entra di richiedere un token di accesso ed eseguire l'autenticazione all'app di destinazione. Se si vuole applicare anche l'autorizzazione per consentire solo determinate applicazioni client, è necessario eseguire una configurazione aggiuntiva.

  1. Definire un ruolo dell'app nel manifesto della registrazione dell'app che rappresenta l'App Service o l'app Funzioni di Azure che si desidera proteggere.

  2. Nella registrazione dell'app che rappresenta il client che deve essere autorizzato, selezionare API permissions>Aggiungi un'autorizzazione>Le mie API.

  3. Selezionare la registrazione dell'app creata in precedenza. Se la registrazione app non viene visualizzata, assicurarsi di aver aggiunto un ruolo app.

  4. In Autorizzazioni applicazione selezionare il ruolo dell'app creato in precedenza. Quindi seleziona Aggiungi autorizzazioni.

  5. Selezionare Concedi consenso amministratore per autorizzare l'applicazione client a richiedere l'autorizzazione.

    Analogamente allo scenario precedente (prima di aggiungere tutti i ruoli), è ora possibile richiedere un token di accesso per la stessa risorsa di destinazione. Il token di accesso include un'attestazione roles che contiene i ruoli dell'app autorizzati per l'applicazione client.

All'interno del codice del servizio app di destinazione o dell'app Funzioni di Azure, è ora possibile verificare che il token abbia i ruoli previsti. Il Servizio app di autenticazione non esegue questa convalida. Per altre informazioni, vedere Accedere alle attestazioni utente nel codice dell'app.

Ora hai configurato un'applicazione client daemon che può accedere all'app di App Service utilizzando la propria identità.

Procedure consigliate

Indipendentemente dalla configurazione usata per configurare l'autenticazione, le procedure consigliate seguenti mantengono più sicuro il tenant e le applicazioni:

  • Configurare ogni app di Servizio app con una propria registrazione dell'app in Microsoft Entra.
  • Assegna a ogni app di App Service le proprie autorizzazioni e il consenso.
  • Evitare la condivisione delle autorizzazioni tra ambienti. Usare registrazioni di app separate per slot di distribuzione separati. Quando si testa un nuovo codice, questa procedura può aiutare a evitare problemi che influiscono sull'app di produzione.

Eseguire la migrazione a Microsoft Graph

Alcune app meno recenti potrebbero essere configurate con una dipendenza da Azure AD Graph, deprecata e pianificata per il ritiro completo. Ad esempio, il codice dell'app potrebbe chiamare Azure AD Graph per controllare l'appartenenza al gruppo come parte di un filtro di autorizzazione in una pipeline middleware. Le app devono passare a Microsoft Graph. Per altre informazioni, vedere Eseguire la migrazione delle app da Azure AD Graph a Microsoft Graph.

Durante questa migrazione, potrebbe essere necessario apportare alcune modifiche alla configurazione dell'autenticazione di servizio app. Dopo aver aggiunto le autorizzazioni di Microsoft Graph alla registrazione dell'app, è possibile:

  • Aggiorna il valore URL emittente per includere il /v2.0 suffisso se non lo include già.

  • Rimuovere le richieste di autorizzazioni di Azure AD Graph dalla configurazione di accesso. Le proprietà da modificare dipendono da quale versione dell'API di gestione si sta usando:

    • Se si usa l'API V1 (/authsettings), questa impostazione si trova nella additionalLoginParams matrice.
    • Se si usa l'API V2 (/authsettingsV2), questa impostazione si trova nella loginParameters matrice.

    È necessario rimuovere qualsiasi riferimento a https://graph.windows.net, ad esempio. Questa modifica include il resource parametro che l'endpoint /v2.0 non supporta. Include anche tutti gli ambiti richiesti specificamente da Azure AD Graph.

    È anche necessario aggiornare la configurazione per richiedere le nuove autorizzazioni di Microsoft Graph configurate per la registrazione dell'applicazione. In molti casi, è possibile usare l'ambito predefinito per semplificare questa configurazione. A tale scopo, aggiungere un nuovo parametro di accesso: scope=openid profile email https://graph.microsoft.com/.default.

Con queste modifiche, quando l'autenticazione del servizio app tenta di accedere, non richiede più le autorizzazioni ad Azure AD Graph. Ottiene invece un token per Microsoft Graph. Qualsiasi uso di tale token dal codice dell'applicazione deve anche essere aggiornato, come descritto in Eseguire la migrazione delle app da Azure AD Graph a Microsoft Graph.

Contenuti correlati