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 ao usar 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 usuários finais autenticados do aplicativo ou os aplicativos cliente fazem declarações em tokens de entrada. O Serviço de Aplicativo disponibiliza as declarações ao 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, elas só estarão presentes se o Serviço de Aplicativo os definir.

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 informações necessárias dos cabeçalhos de 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 X-MS-TOKEN-AAD-ACCESS-TOKEN e X-MS-TOKEN-AAD-ID-TOKEN os cabeçalhos de token do provedor conforme apropriado.

Decodificar o cabeçalho da entidade de segurança do cliente

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

A estrutura de conteúdo decodificada é 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 que a estrutura de idiomas do aplicativo usa. 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 por meio de principal.Claims para verificar 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 da estrutura

• Para ASP.NET 4.6 aplicativos, o Serviço de Aplicativo preenche ClaimsPrincipal.Current com as declarações do usuário autenticado. Você pode seguir o padrão de código .NET padrão, incluindo o [Authorize] atributo.

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

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

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

• Para o .NET Core, Microsoft.Identity.Web dá suporte ao preenchimento do usuário atual com a autenticação do Serviço de Aplicativo. Para obter mais informações, consulte Integração com os Serviços de Aplicativo do Azure autenticação de aplicativos Web em execução 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 protegido como o 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á chamar /.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 usuários de ponta a ponta