Работа с удостоверениями пользователей при проверке подлинности в Службе приложений Azure

В этой статье показано, как работать с удостоверениями пользователей при использовании встроенной проверки подлинности и авторизации в Службе приложений Azure.

Предпосылки

Веб-приложение, работающее в Службе приложений Azure с включенным модулем проверки подлинности и авторизации службы приложений.

Доступ к утверждениям пользователей в коде приложения

Прошедшие проверку подлинности конечные пользователи или клиентские приложения делают утверждения в входящих токенах. Служба приложений делает утверждения доступными для кода, внедряя их в заголовки запросов. Внешние запросы не могут задавать эти заголовки, поэтому они присутствуют только в том случае, если служба приложений задает их.

Вы можете использовать сведения о утверждениях, которые предоставляет проверка подлинности службы приложений для выполнения проверок авторизации в коде приложения. Код на любом языке или платформе может получить необходимые сведения из заголовков запроса. Некоторые платформы кода предоставляют дополнительные параметры, которые могут быть более удобными. См. альтернативные варианты для конкретной платформы.

В следующей таблице описаны некоторые примеры заголовков:

Аналогичные заголовки раскрывают маркеры поставщика. Например, Microsoft Entra устанавливает заголовки токенов поставщика X-MS-TOKEN-AAD-ACCESS-TOKEN и X-MS-TOKEN-AAD-ID-TOKEN соответствующим образом.

Декодирование клиентского главного заголовка

Заголовок X-MS-CLIENT-PRINCIPAL содержит полный набор доступных утверждений в формате JSON в кодировке Base64. Чтобы обработать этот заголовок, приложение должно декодировать полезные данные и выполнять итерацию по массиву claims , чтобы найти соответствующие утверждения.

Декодированная структура полезных данных выглядит следующим образом:

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

В следующей таблице описаны свойства.

Для удобства можно преобразовать утверждения в представление, которое использует языковая платформа приложения. Следующий пример C# создает тип ClaimsPrincipal, который будет использовать приложение.

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

На этом этапе код может выполнять итерацию через principal.Claims, чтобы проверить утверждения как часть процесса проверки. Кроме того, можно преобразовать principal.Claims в стандартный объект и использовать его для выполнения этих проверок позже в конвейере запроса. Этот объект также можно использовать для связывания пользовательских данных и других целей.

Остальная часть функции выполняет это преобразование, чтобы создать ClaimsPrincipal объект, который можно использовать в другом коде .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);
    }
}

Альтернативные варианты для конкретной платформы

• Для приложений ASP.NET версии 4.6 App Service заполняет ClaimsPrincipal.Current утверждениями пользователей, прошедших проверку подлинности. Вы можете следовать стандартному шаблону кода .NET, включая [Authorize] атрибут.

  ClaimsPrincipal.Current не заполняется кодом .NET в Функциях Azure, но вы по-прежнему можете найти утверждения пользователя в заголовках запроса или получить ClaimsPrincipal объект из контекста запроса или с помощью параметра привязки. Дополнительные сведения см. в статье "Работа с удостоверениями клиентов" в Функциях Azure.

• Для приложений PHP служба приложений аналогично заполняет _SERVER['REMOTE_USER'] переменную.

• Для приложений Java утверждения доступны из сервлета Tomcat.

• Для .NET Core Microsoft.Identity.Web поддерживает заполнение данных о текущем пользователе с помощью аутентификации службы приложений. Дополнительные сведения см. в статье "Интеграция с проверкой подлинности служб приложений Azure" для веб-приложений, работающих с Microsoft.Identity.Web. Чтобы получить демонстрацию того, как веб-приложение обращается к Microsoft Graph, см. Учебник: Доступ к Microsoft Graph из защищенного .NET-приложения от имени пользователя.

Доступ к утверждениям пользователей с помощью API

Если хранилище маркеров включено для вашего приложения, вы также можете использовать /.auth/me для получения дополнительной информации о пользователе, который был аутентифицирован.

Связанный контент

• Проверка подлинности и авторизация в Службе приложений и Службе функций Azure
• Руководство: Полная проверка подлинности и авторизация пользователей