Usare le identità utente nell'autenticazione del servizio app di Azure

Questo articolo illustra come usare le identità utente quando si usano l'autenticazione e l'autorizzazione predefinite nel servizio app di Azure.

Prerequisiti

Un'applicazione Web in esecuzione nel Servizio app di Azure con il modulo di autenticazione/autorizzazione del servizio app abilitato.

Accedere alle attestazioni utente nel codice dell'app

Gli utenti finali autenticati o le applicazioni client dell'app effettuano attestazioni nei token in ingresso. Il servizio app rende le attestazioni disponibili per il codice inserendole nelle intestazioni della richiesta. Alle richieste esterne non è consentito impostare queste intestazioni, che sono quindi presenti solo se impostate dal servizio app.

È possibile usare le informazioni sulle attestazioni fornite dall'autenticazione del servizio app per eseguire i controlli di autorizzazione nel codice dell'app. Il codice in qualsiasi linguaggio o framework può ottenere informazioni necessarie dalle intestazioni della richiesta. Alcuni framework di codice offrono opzioni aggiuntive che potrebbero risultare più utili. Vedere Alternative specifiche del framework.

La tabella seguente descrive alcune intestazioni di esempio:

Intestazioni simili espongono token delprovider. Ad esempio, Microsoft Entra imposta X-MS-TOKEN-AAD-ACCESS-TOKEN e X-MS-TOKEN-AAD-ID-TOKEN le intestazioni del token del provider in base alle esigenze.

Decodificare l'intestazione dell'entità client

L'intestazione X-MS-CLIENT-PRINCIPAL contiene il set completo di attestazioni disponibili in JSON con codifica Base64. Per elaborare questa intestazione, l'app deve decodificare il payload ed eseguire l'iterazione della matrice claims per trovare le attestazioni pertinenti.

La struttura del payload decodificato è la seguente:

{
    "auth_typ": "",
    "claims": [
        {
            "typ": "",
            "val": ""
        }
    ],
    "name_typ": "",
    "role_typ": ""
}

Nella tabella seguente vengono descritte le proprietà.

Per praticità, è possibile convertire le attestazioni in una rappresentazione usata dal framework del linguaggio dell'app. L'esempio C# seguente costruisce un ClaimsPrincipal tipo da usare per l'app.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Claims;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;
using Microsoft.AspNetCore.Http;

public static class ClaimsPrincipalParser
{
    private class ClientPrincipalClaim
    {
        [JsonPropertyName("typ")]
        public string Type { get; set; }
        [JsonPropertyName("val")]
        public string Value { get; set; }
    }

    private class ClientPrincipal
    {
        [JsonPropertyName("auth_typ")]
        public string IdentityProvider { get; set; }
        [JsonPropertyName("name_typ")]
        public string NameClaimType { get; set; }
        [JsonPropertyName("role_typ")]
        public string RoleClaimType { get; set; }
        [JsonPropertyName("claims")]
        public IEnumerable<ClientPrincipalClaim> Claims { get; set; }
    }

    public static ClaimsPrincipal Parse(HttpRequest req)
    {
        var principal = new ClientPrincipal();

        if (req.Headers.TryGetValue("x-ms-client-principal", out var header))
        {
            var data = header[0];
            var decoded = Convert.FromBase64String(data);
            var json = Encoding.UTF8.GetString(decoded);
            principal = JsonSerializer.Deserialize<ClientPrincipal>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
        }

A questo punto, il codice può scorrere principal.Claims per controllare le attestazioni come parte della convalida. In alternativa, è possibile convertire principal.Claims in un oggetto standard e usarlo per eseguire tali controlli in un secondo momento nella pipeline della richiesta. È anche possibile usare tale oggetto per associare i dati utente e per altri usi.

Il resto della funzione esegue questa conversione per creare un ClaimsPrincipal oggetto che può essere usato in altro codice .NET.

        var identity = new ClaimsIdentity(principal.IdentityProvider, principal.NameClaimType, principal.RoleClaimType);
        identity.AddClaims(principal.Claims.Select(c => new Claim(c.Type, c.Value)));
        
        return new ClaimsPrincipal(identity);
    }
}

Alternative specifiche del framework

• Per le app ASP.NET 4.6, il servizio app popola ClaimsPrincipal.Current con le attestazioni dell'utente autenticato. È possibile seguire il modello di codice .NET standard, incluso l'attributo [Authorize] .

  Per Funzioni di Azure, ClaimsPrincipal.Current non viene popolato per il codice .NET, ma è comunque possibile trovare le attestazioni utente nelle intestazioni della richiesta o ottenere l'oggetto ClaimsPrincipal dal contesto della richiesta o anche tramite un parametro di associazione. Per altre informazioni, vedere Usare le identità client in Funzioni di Azure.

• Per le app PHP, il servizio app popola in modo analogo la _SERVER['REMOTE_USER'] variabile.

• Per le app Java, le attestazioni sono accessibili dal servlet Tomcat.

• Per .NET Core, Microsoft.Identity.Web supporta il popolamento dell'utente corrente con l'autenticazione del Servizio app. Per altre informazioni, vedere Integrazione con l'autenticazione dei servizi app di Azure delle app Web in esecuzione con Microsoft.Identity.Web. Per una dimostrazione di un'app Web che accede a Microsoft Graph, vedere Esercitazione: Accedere a Microsoft Graph da un'app .NET protetta come utente.

Accedere alle attestazioni utente usando l'API

Se l'archivio token è abilitato per l'app, è anche possibile ottenere altri dettagli sull'utente autenticato chiamando /.auth/me.

Contenuti correlati

• Autenticazione e autorizzazione nel Servizio app di Azure e Funzioni di Azure
• Esercitazione: Autenticare e autorizzare gli utenti da inizio a fine