Praca z tożsamościami użytkowników w uwierzytelnianiu usługi aplikacja systemu Azure Service

Artykuł
05/21/2024

W tym artykule pokazano, jak pracować z tożsamościami użytkowników podczas korzystania z wbudowanego uwierzytelniania i autoryzacji w usłudze App Service.

Uzyskiwanie dostępu do oświadczeń użytkowników w kodzie aplikacji

W przypadku wszystkich struktur językowych usługa App Service przekazuje oświadczenia w tokenie przychodzącym (niezależnie od tego, czy od uwierzytelnionego użytkownika końcowego, czy aplikacji klienckiej) jest dostępne dla kodu, wstrzykiwając je do nagłówków żądań. Żądania zewnętrzne nie mogą ustawiać tych nagłówków, dlatego są obecne tylko w przypadku ustawienia przez usługę App Service. Oto przykładowe nagłówki:

Nagłówek	opis
`X-MS-CLIENT-PRINCIPAL`	Zakodowana w formacie Base64 reprezentacja dostępnych oświadczeń w formacie JSON. Aby uzyskać więcej informacji, zobacz Dekodowanie nagłówka podmiotu zabezpieczeń klienta.
`X-MS-CLIENT-PRINCIPAL-ID`	Identyfikator elementu wywołującego ustawionego przez dostawcę tożsamości.
`X-MS-CLIENT-PRINCIPAL-NAME`	Czytelna dla człowieka nazwa obiektu wywołującego ustawionego przez dostawcę tożsamości, taka jak adres e-mail lub główna nazwa użytkownika.
`X-MS-CLIENT-PRINCIPAL-IDP`	Nazwa dostawcy tożsamości używanego przez uwierzytelnianie usługi App Service.

Tokeny dostawcy są również udostępniane za pośrednictwem podobnych nagłówków. Na przykład firma Microsoft Entra również ustawia X-MS-TOKEN-AAD-ACCESS-TOKEN i X-MS-TOKEN-AAD-ID-TOKEN odpowiednio.

Uwaga

Różne struktury językowe mogą przedstawiać te nagłówki do kodu aplikacji w różnych formatach, takich jak małe litery lub wielkość tytułu.

Kod napisany w dowolnym języku lub strukturze może uzyskać informacje potrzebne z tych nagłówków. Dekodowanie nagłówka podmiotu zabezpieczeń klienta obejmuje ten proces. W przypadku niektórych struktur platforma udostępnia również dodatkowe opcje, które mogą być wygodniejsze.

Dekodowanie nagłówka podmiotu zabezpieczeń klienta

X-MS-CLIENT-PRINCIPAL zawiera pełny zestaw dostępnych oświadczeń jako kodowany kod JSON base64. Te oświadczenia przechodzą przez domyślny proces mapowania oświadczeń, więc niektóre mogą mieć inne nazwy niż w przypadku bezpośredniego przetwarzania tokenu. Zdekodowany ładunek jest ustrukturyzowany w następujący sposób:

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

Właściwość	Type	opis
`auth_typ`	string	Nazwa dostawcy tożsamości używanego przez uwierzytelnianie usługi App Service.
`claims`	tablica obiektów	Tablica obiektów reprezentujących dostępne oświadczenia. Każdy obiekt zawiera `typ` właściwości i `val` .
`typ`	string	Nazwa oświadczenia. Może on podlegać mapowaniu oświadczeń domyślnych i może różnić się od odpowiedniego oświadczenia zawartego w tokenie.
`val`	string	Wartość oświadczenia.
`name_typ`	string	Typ oświadczenia nazwy, który jest zazwyczaj identyfikatorem URI dostarczającym informacje o schemacie oświadczenia `name` , jeśli jest zdefiniowany.
`role_typ`	string	Typ oświadczenia roli, który jest zazwyczaj identyfikatorem URI dostarczającym informacje o schemacie oświadczenia `role` , jeśli jest zdefiniowany.

Aby przetworzyć ten nagłówek, aplikacja musi zdekodować ładunek i iterować przez tablicę claims , aby znaleźć interesujące oświadczenia. Może być wygodne przekonwertowanie ich na reprezentację używaną przez platformę języka aplikacji. Oto przykład tego procesu w języku C#, który tworzy typ ClaimsPrincipal dla aplikacji do użycia:

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

        /** 
         *  At this point, the code can iterate through `principal.Claims` to
         *  check claims as part of validation. Alternatively, we can convert
         *  it into a standard object with which to perform those checks later
         *  in the request pipeline. That object can also be leveraged for 
         *  associating user data, etc. The rest of this function performs such
         *  a conversion to create a `ClaimsPrincipal` as might be used in 
         *  other .NET code.
         */

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

Alternatywy specyficzne dla struktury

W przypadku aplikacji ASP.NET 4.6 usługa App Service wypełnia wartość ClaimsPrincipal.Current oświadczeniami uwierzytelnionych użytkowników, aby można było postępować zgodnie ze standardowym wzorcem kodu platformy .NET, w tym atrybutem [Authorize] . Podobnie w przypadku aplikacji PHP usługa App Service wypełnia zmienną _SERVER['REMOTE_USER'] . W przypadku aplikacji Java oświadczenia są dostępne z serwletu Tomcat.

W przypadku usługi Azure FunctionsClaimsPrincipal.Current nie jest wypełniany dla kodu platformy .NET, ale nadal można znaleźć oświadczenia użytkownika w nagłówkach żądania lub pobrać ClaimsPrincipal obiekt z kontekstu żądania, a nawet za pomocą parametru powiązania. Aby uzyskać więcej informacji, zobacz Praca z tożsamościami klientów w usłudze Azure Functions.

W przypadku platformy .NET Core platforma Microsoft.Identity.Web obsługuje wypełnianie bieżącego użytkownika przy użyciu uwierzytelniania usługi App Service. Aby dowiedzieć się więcej, możesz przeczytać o niej w witrynie typu wiki Microsoft.Identity.Web lub zapoznać się z nią w tym samouczku dotyczącym aplikacji internetowej, która uzyskuje dostęp do programu Microsoft Graph.

Uwaga

Aby mapowanie oświadczeń działało, należy włączyć magazyn tokenów.

Uzyskiwanie dostępu do oświadczeń użytkowników przy użyciu interfejsu API

Jeśli magazyn tokenów jest włączony dla aplikacji, możesz również uzyskać inne szczegóły dotyczące uwierzytelnionego użytkownika, wywołując metodę /.auth/me.

Następne kroki

Samouczek: kompleksowe uwierzytelnianie i autoryzacja użytkowników

Udostępnij za pośrednictwem