Teilen über

Arbeiten mit Benutzeridentitäten bei der Authentifizierung in Azure App Service

In diesem Artikel erfahren Sie, wie Sie mit Benutzeridentitäten arbeiten, wenn Sie integrierte Authentifizierung und Autorisierung in Azure App Service verwenden.

Voraussetzungen

Eine unter Azure App Service ausgeführte Webanwendung, für die das App Service-Modul für die Authentifizierung/Autorisierung aktiviert ist.

Zugreifen auf Benutzeransprüche in App-Code

Authentifizierte Endbenutzer oder Client-Anwendungen Ihrer App stellen Behauptungen in eingehenden Token. Der App Service macht die Ansprüche für Ihren Code verfügbar, indem er sie in Anforderungsheadern einfügt. Externe Anforderungen dürfen diese Header nicht festlegen, sodass sie nur vorhanden sind, wenn Der App-Dienst sie festlegt.

Sie können die Anspruchsinformationen verwenden, die die App Service-Authentifizierung bereitstellt, um Autorisierungsprüfungen in Ihrem App-Code durchzuführen. Code in einer beliebigen Sprache oder einem beliebigen Framework kann erforderliche Informationen aus den Anforderungsheadern abrufen. Einige Codeframeworks bieten zusätzliche Optionen, die möglicherweise bequemer sind. Siehe Frameworkspezifische Alternativen.

In der folgenden Tabelle werden einige Beispielüberschriften beschrieben:

Kopfzeile BESCHREIBUNG
X-MS-CLIENT-PRINCIPAL Eine base64-codierte JSON-Darstellung verfügbarer Ansprüche. Weitere Informationen finden Sie unter Decodierung des Client-principal-Headers.
X-MS-CLIENT-PRINCIPAL-ID Ein Bezeichner, den der Identitätsanbieter für den Aufrufer festlegt.
X-MS-CLIENT-PRINCIPAL-NAME Ein lesbarer Name, den der Identitätsanbieter für den Anrufer festlegt, z. B. eine E-Mail-Adresse oder einen Benutzerprinzipalnamen.
X-MS-CLIENT-PRINCIPAL-IDP Der Name des Identitätsanbieters, den die App Service-Authentifizierung verwendet.

Ähnliche Header machen Anbietertoken verfügbar. Microsoft Entra legt die Anbietertokenheader X-MS-TOKEN-AAD-ACCESS-TOKEN und X-MS-TOKEN-AAD-ID-TOKEN sinnvoll fest.

Hinweis

Der App-Dienst stellt die Anforderungsheader für alle Sprachframeworks zur Verfügung. Verschiedene Sprachenframeworks zeigen diese Header im App-Code möglicherweise in verschiedenen Formaten an (klein geschrieben oder mit großen Anfangsbuchstaben).

Das Decodieren des Client-Principal-Headers

Der Header enthält den vollständigen Satz verfügbarer Ansprüche in Base64-codiertem JSON.The X-MS-CLIENT-PRINCIPAL header contains the full set of available claims in Base64-encoded JSON. Um diesen Header zu verarbeiten, muss Ihre App die Nutzlast decodieren und das claims Array durchlaufen, um relevante Ansprüche zu finden.

Hinweis

Diese Ansprüche werden einem standardmäßigen Anspruchszuordnungsprozess unterzogen, sodass einige Namen möglicherweise anders sind als in den Token.

Die decodierte Nutzlaststruktur lautet wie folgt:

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

In der folgenden Tabelle werden die Eigenschaften beschrieben.

Eigenschaft type BESCHREIBUNG
auth_typ Zeichenfolge Der Name des Identitätsanbieters, den die App Service-Authentifizierung verwendet.
claims array Ein Array von Objekten, die die verfügbaren Ansprüche darstellen. Jedes Objekt enthält die Eigenschaften typ und val.
typ Zeichenfolge Der Name des Anspruchs, der möglicherweise der Standardanspruchszuordnung unterliegt und sich von dem entsprechenden Anspruch im Token unterscheidet.
val Zeichenfolge Der Wert des Anspruchs.
name_typ Zeichenfolge Der Namensanspruchstyp, in der Regel ein URI, der Schemainformationen zum name-Anspruch bereitstellt, wenn einer definiert ist.
role_typ Zeichenfolge Der Rollenanspruchstyp, der normalerweise ein URI ist, der Schemainformationen über den role-Anspruch bereitstellt, falls einer definiert ist.

Aus Gründen der Einfachheit können Sie Ansprüche in eine Darstellung konvertieren, die das Sprachframework der App verwendet. Im folgenden C#-Beispiel wird ein ClaimsPrincipal Typ für die zu verwendende App erstellt.

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

An diesem Punkt kann der Code durch principal.Claims iterieren, um Forderungen als Teil der Verifizierung zu validieren. Alternativ können Sie principal.Claims in ein Standardobjekt konvertieren und die Option nutzen, diese Prüfungen später in der Anforderungspipeline durchzuführen. Sie können dieses Objekt auch verwenden, um Benutzerdaten und andere Verwendungen zuzuordnen.

Der Rest der Funktion führt diese Konvertierung aus, um eine ClaimsPrincipal Konvertierung zu erstellen, die in anderen .NET-Code verwendet werden kann.

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

Frameworkspezifische Alternativen

Hinweis

Damit die Anspruchszuordnung funktioniert, müssen Sie den Tokenspeicher für Ihre App aktivieren.

Zugreifen auf Benutzeransprüche mithilfe der API

Wenn der Tokenspeicher für Ihre App aktiviert ist, können Sie auch aufrufen /.auth/me , um weitere Details zum authentifizierten Benutzer abzurufen.

Verwandte Inhalte

  • Last updated on