Trabalhar com identidades de usuário na autenticação do Serviço de Aplicativo do Azure

Este artigo mostra como trabalhar com identidades de usuário quando você usa autenticação e autorização internas no Serviço de Aplicativo do Azure.

Pré-requisitos

Um aplicativo Web em execução no Serviço de Aplicativo do Azure que tem o módulo de autenticação/autorização do Serviço de Aplicativo habilitado.

Acessar declarações de usuário no código do aplicativo

Os utilizadores finais autenticados ou aplicações cliente do seu aplicativo apresentam reivindicações nos tokens recebidos. O Serviço de Aplicativo disponibiliza as declarações para seu código injetando-as em cabeçalhos de solicitação. As solicitações externas não têm permissão para definir esses cabeçalhos, portanto, eles estão presentes apenas se o Serviço de Aplicativo defini-los.

Você pode usar as informações de declarações que a autenticação do Serviço de Aplicativo fornece para executar verificações de autorização no código do aplicativo. O código em qualquer linguagem ou estrutura pode obter as informações necessárias dos cabeçalhos da solicitação. Algumas estruturas de código fornecem opções extras que podem ser mais convenientes. Consulte Alternativas específicas do framework.

A tabela a seguir descreve alguns cabeçalhos de exemplo:

Cabeçalhos semelhantes expõem tokens de provedor. Por exemplo, o Microsoft Entra define os cabeçalhos de token de provedor X-MS-TOKEN-AAD-ACCESS-TOKEN e X-MS-TOKEN-AAD-ID-TOKEN conforme apropriado.

Decodificar o cabeçalho principal do cliente

O X-MS-CLIENT-PRINCIPAL cabeçalho contém o conjunto completo de declarações disponíveis em JSON codificado em Base64. Para processar esse cabeçalho, seu aplicativo deve decodificar a carga útil e iterar através da claims matriz para encontrar declarações relevantes.

A estrutura de carga útil descodificada é a seguinte:

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

A tabela a seguir descreve as propriedades.

Por conveniência, você pode converter declarações em uma representação usada pela estrutura de linguagem do aplicativo. O exemplo de C# a seguir constrói um ClaimsPrincipal tipo para o aplicativo usar.

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

Neste ponto, o código pode iterar para principal.Claims verificar as declarações como parte da validação. Como alternativa, você pode converter principal.Claims em um objeto padrão e usá-lo para fazer essas verificações posteriormente no pipeline de solicitação. Você também pode usar esse objeto para associar dados do usuário e para outros usos.

O restante da função executa essa conversão para criar um ClaimsPrincipal que pode ser usado em outro código .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);
    }
}

Alternativas específicas ao quadro

• Para aplicações ASP.NET 4.6, o Serviço de Aplicações preenche ClaimsPrincipal.Current com as afirmações do utilizador autenticado. Você pode seguir o padrão de código .NET padrão, incluindo o [Authorize] atributo.

  ClaimsPrincipal.Current não está preenchido para código .NET no Azure Functions, mas você ainda pode encontrar as declarações de usuário nos cabeçalhos de solicitação ou obter o ClaimsPrincipal objeto do contexto da solicitação ou por meio de um parâmetro de vinculação. Para obter mais informações, consulte Trabalhar com identidades de cliente no Azure Functions.

• Para aplicativos PHP, o Serviço de Aplicativo preenche a _SERVER['REMOTE_USER'] variável de forma semelhante.

• Para aplicativos Java, as declarações são acessíveis a partir do servlet Tomcat.

• Para o .NET Core, Microsoft.Identity.Web suporta o preenchimento do utilizador atual com a autenticação do App Service. Para obter mais informações, consulte Integração com a autenticação dos Serviços de Aplicativo do Azure de aplicativos Web executados com Microsoft.Identity.Web. Para obter uma demonstração de um aplicativo Web acessando o Microsoft Graph, consulte Tutorial: Acessar o Microsoft Graph de um aplicativo .NET seguro como usuário.

Acessar declarações de usuário usando a API

Se o repositório de tokens estiver habilitado para seu aplicativo, você também poderá ligar /.auth/me para obter outros detalhes sobre o usuário autenticado.

Conteúdo relacionado

• Autenticação e autorização no Serviço de Aplicativo do Azure e no Azure Functions
• Tutorial: Autenticar e autorizar utilizadores de início a fim