Dela via

Arbeta med användaridentiteter i Azure App Service-autentisering

Den här artikeln visar hur du arbetar med användaridentiteter när du använder inbyggd autentisering och auktorisering i Azure App Service.

Förutsättningar

Ett webbprogram som körs på Azure App Service som har modulen autentisering/auktorisering för App Service aktiverad.

Åtkomst till användarkrav i applikationskod

Appens autentiserade slutanvändare eller klientprogram gör anspråk på inkommande tokens. App Service gör anspråken tillgängliga för din kod genom att mata in dem i begärandehuvuden. Externa begäranden tillåts inte att ange dessa rubriker, så de finns bara om App Service anger dem.

Du kan använda anspråksinformationen som App Service-autentisering tillhandahåller för att utföra auktoriseringskontroller i din appkod. Kod på valfritt språk eller ramverk kan hämta nödvändig information från begärandehuvudena. Vissa kodramverk ger extra alternativ som kan vara mer praktiska. Se Ramverksspecifika alternativ.

I följande tabell beskrivs några exempelrubriker:

Rubrik Beskrivning
X-MS-CLIENT-PRINCIPAL En Base64-kodad JSON-representation av tillgängliga anspråk. Mer information finns i Avkoda klientens titelhuvud.
X-MS-CLIENT-PRINCIPAL-ID En identifierare som identitetsprovidern anger för anroparen.
X-MS-CLIENT-PRINCIPAL-NAME Ett läsbart namn som identitetsprovidern anger för anroparen, till exempel en e-postadress eller användarens huvudnamn.
X-MS-CLIENT-PRINCIPAL-IDP Namnet på den identitetsprovider som App Service-autentisering använder.

Liknande rubriker exponerar providertoken. Microsoft Entra ställer in X-MS-TOKEN-AAD-ACCESS-TOKEN och X-MS-TOKEN-AAD-ID-TOKEN leverantörens tokenhuvuden efter behov.

Anmärkning

App Service gör begäranderubrikerna tillgängliga för alla språkramverk. Olika språkramverk kan presentera dessa rubriker för appkoden i olika format, till exempel gemener eller rubrikfall.

Avkoda klienthuvudhuvudet

Rubriken X-MS-CLIENT-PRINCIPAL innehåller den fullständiga uppsättningen tillgängliga anspråk i Base64-kodad JSON. För att hantera denna header måste appen dekoda nyttolasten och iterera genom matrisen claims för att hitta relevanta påståenden.

Anmärkning

Dessa anspråk genomgår en standardprocess för mappning av anspråk, så vissa namn kan skilja sig från de som visas i token.

Den avkodade nyttolaststrukturen är följande:

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

I följande tabell beskrivs egenskaperna.

Fastighet Type Beskrivning
auth_typ string Namnet på den identitetsprovider som App Service-autentisering använder.
claims array En matris med objekt som representerar tillgängliga anspråk. Varje objekt innehåller typ och val egenskaper.
typ string Namnet på anspråket, som kan omfattas av standardmappning av anspråk och skilja sig från motsvarande anspråk i token.
val string Anspråkets värde.
name_typ string Namnanspråkstypen, som vanligtvis är en URI som tillhandahåller schemainformation om anspråket name om ett är definierat.
role_typ string Rollanspråkstypen, som vanligtvis är en URI som tillhandahåller schemainformation om anspråket role om det har definierats.

För enkelhetens skull kan du konvertera anspråk till en representation som appens språkramverk använder. I följande C#-exempel skapas en ClaimsPrincipal typ som appen ska använda.

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 });
        }

I det här läget kan koden iterera igenom principal.Claims för att kontrollera anspråk som en del av valideringen. Du kan också konvertera principal.Claims till ett standardobjekt och använda det för att utföra dessa kontroller senare i pipelinen för begäran. Du kan också använda objektet för att associera användardata och för andra användningsområden.

Resten av funktionen utför den här konverteringen för att skapa en ClaimsPrincipal som kan användas i annan .NET-kod.

        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);
    }
}

Ramverksspecifika alternativ

Anmärkning

För att anspråksmappning ska fungera måste du aktivera tokenarkivet för din app.

Få åtkomst till användarkrav med hjälp av API:et

Om tokenarkivet är aktiverat för din app kan du även anropa /.auth/me för att hämta annan information om den autentiserade användaren.

Relaterat innehåll