Partilhar via

Autenticação Remota

  • Artigo

O recurso de autenticação remota dos adaptadores do System.Web permite que um aplicativo do ASP.NET Core determine a identity de um usuário (autenticar uma solicitação HTTP) adiando a autenticação para um aplicativo do ASP.NET. Habilitar o recurso adiciona um ponto de extremidade ao aplicativo ASP.NET que retorna um ClaimsPrincipal serializado que representa o usuário autenticado para quaisquer solicitações feitas ao ponto de extremidade. O aplicativo do ASP.NET Core então registra um manipulador de autenticação personalizado que (para pontos de extremidade com autenticação remota habilitada) determinará a identity de um usuário chamando esse ponto de extremidade no aplicativo ASP.NET e passando cabeçalhos e cookies selecionados da solicitação original recebida pelo aplicativo do ASP.NET Core.

Configuração

Há apenas algumas pequenas alterações de código necessárias para habilitar a autenticação remota em uma solução que já está configurada de acordo com a seção Introdução.

Primeiro, siga as instruções de configuraçãor remota de aplicativo para conectar os aplicativos ASP.NET Core e ASP.NET. Em seguida, há apenas alguns métodos de extensão extras a serem chamados para habilitar a autenticação remota do aplicativo.

configuração do aplicativo ASP.NET

O aplicativo ASP.NET precisa ser configurado para adicionar o ponto de extremidade de autenticação. A adição do ponto de extremidade de autenticação é feita chamando o método de extensão AddAuthenticationServer para configurar o módulo HTTP que observa as solicitações para o ponto de extremidade de autenticação. Observe que os cenários de autenticação remota normalmente querem adicionar o suporte de proxy também, de modo que todos os redirecionamentos relacionados à autenticação sejam roteados corretamente para o aplicativo ASP.NET Core em vez do ASP.NET.

SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .AddProxySupport(options => options.UseForwardedHeaders = true)
    .AddRemoteAppServer(options =>
    {
        options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
    })
    .AddAuthenticationServer();

configuração do aplicativo ASP.NET Core

Em seguida, o aplicativo ASP.NET Core precisa ser configurado para habilitar o identificador de autenticação que autenticará os usuários fazendo uma solicitação HTTP para o aplicativo ASP.NET. Novamente, isso é feito chamando AddAuthenticationClient ao registrar serviços de adaptadores do System.Web:

builder.Services.AddSystemWebAdapters()
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration
            ["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true);

O booliano que é passado para a chamada AddAuthenticationClient especifica se a autenticação remota de aplicativo deve ser o esquema de autenticação padrão. Passar true fará com que o usuário seja autenticado por meio da autenticação remota de aplicativo para todas as solicitações, enquanto passar false significa que o usuário só será autenticado com autenticação remota de aplicativo se o esquema de aplicativo remoto for solicitado especificamente (com [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] em um controlador ou método de ação, por exemplo). Passar false para esse parâmetro tem a vantagem de fazer apenas solicitações HTTP para o aplicativo de ASP.NET original para autenticação para pontos de extremidade que exigem autenticação de aplicativo remoto, mas tem a desvantagem de exigir a anotação de todos esses pontos de extremidade para indicar que eles usarão autenticação de aplicativo remoto.

Além do booliano necessário, um retorno de chamada opcional pode ser passado para AddAuthenticationClient modificar alguns outros aspectos do comportamento do processo de autenticação remota:

  • RequestHeadersToForward: essa propriedade contém cabeçalhos que devem ser encaminhados de uma solicitação ao chamar a API de autenticação. Por padrão, os únicos cabeçalhos encaminhados são Authorization e Cookie. Cabeçalhos adicionais podem ser encaminhados adicionando-os a esta lista. Como alternativa, se a lista estiver desmarcada (para que nenhum cabeçalho seja especificado), todos os cabeçalhos serão encaminhados.
  • ResponseHeadersToForward: essa propriedade lista os cabeçalhos de resposta que devem ser propagados de volta da solicitação de autenticação para a chamada original que motivou a autenticação em cenários em que a identity é contestada. Por padrão, isso inclui cabeçalhos Location , Set-Cookiee WWW-Authenticate .
  • AuthenticationEndpointPath: o ponto de extremidade no aplicativo ASP.NET em que as solicitações de autenticação devem ser feitas. Esse padrão é /systemweb-adapters/authenticate e deve corresponder ao ponto de extremidade especificado na configuração do ponto de extremidade de autenticação do ASP.NET.

Por fim, se o aplicativo ASP.NET Core não incluir o middleware de autenticação anteriormente, isso precisará ser habilitado (após o middleware de roteamento, mas antes do middleware de autorização):

app.UseAuthentication();

Design

  1. Quando as solicitações são processadas pelo aplicativo ASP.NET Core, se a autenticação remota de aplicativo for o esquema padrão ou especificada pelo ponto de extremidade da solicitação, o RemoteAuthenticationAuthHandler tentará autenticar o usuário.
    1. O identificador fará uma solicitação HTTP para o ponto de extremidade autenticado do aplicativo ASP.NET. Ele copiará cabeçalhos configurados da solicitação atual para este novo para encaminhar dados relevantes à autenticação. Conforme mencionado acima, o comportamento padrão é copiar os cabeçalhos Authorize e Cookie . O cabeçalho da chave de API também é adicionado para fins de segurança.
  2. O aplicativo ASP.NET atenderá às solicitações enviadas ao ponto de extremidade de autenticação. Desde que as chaves de API correspondam, o aplicativo ASP.NET retornará o ClaimsPrincipal atual do usuário serializado no corpo da resposta ou retornará um código http status (como 401 ou 302) e cabeçalhos de resposta indicando falha.
  3. Quando o RemoteAuthenticationAuthHandler do aplicativo ASP.NET Core recebe a resposta do aplicativo ASP.NET:
    1. Se um ClaimsPrincipal tiver sido retornado, o identificador de autenticação o desserializará e o usará como a identity atual do usuário.
    2. Se um ClaimsPrincipal não tiver sido retornado com êxito, o identificador armazenará o resultado e, se a autenticação for contestada (porque o usuário está acessando um recurso protegido, por exemplo), a resposta da solicitação será atualizada com o código status e cabeçalhos de resposta selecionados da resposta do ponto de extremidade de autenticação. Isso permite que as respostas de contestação (como redirecionamentos para uma página de logon) sejam propagadas para os usuários finais.
      1. Como os resultados do ponto de extremidade de autenticação do aplicativo ASP.NET podem incluir dados específicos para esse ponto de extremidade, os usuários podem registrar implementações IRemoteAuthenticationResultProcessor com o aplicativo ASP.NET Core que serão executadas em qualquer resultado de autenticação antes de serem usadas. Por exemplo, o IRemoteAuthenticationResultProcessor interno é o RedirectUrlProcessor que procura cabeçalhos de resposta Location retornados do ponto de extremidade de autenticação e garante que eles redirecionem de volta para o host do aplicativo ASP.NET Core e não para o aplicativo ASP.NET diretamente.

Limitações conhecidas

Essa abordagem de autenticação remota tem algumas limitações conhecidas:

  1. Como a autenticação do Windows depende de um identificador para uma identity do Windows, não há suporte para a autenticação do Windows por esse recurso. O trabalho futuro é planejado para explorar como a autenticação do Windows compartilhada pode funcionar. Consulte dotnet/systemweb-adapters#246 para obter mais informações.
  2. Esse recurso permite que o aplicativo ASP.NET Core use uma identity autenticada pelo aplicativo ASP.NET, mas todas as ações relacionadas aos usuários (logon, logoff etc.) ainda precisam ser roteadas por meio do aplicativo ASP.NET.

Alternativas

Se a autenticação no aplicativo ASP.NET for feita usando o Middleware de Autenticação Microsoft.OwinCookie, uma solução alternativa para o compartilhamento da identity será configurar os aplicativos ASP.NET e ASP.NET Core para que eles possam compartilhar um cookie de autenticação. O compartilhamento de um cookie de autenticação permite:

  • Ambos os aplicativos para determinar a identity do usuário do mesmo cookie.
  • Entrar ou sair de um aplicativo conecta o usuário ou o desconecta do outro aplicativo.

Observe que, como a entrada normalmente depende de um banco de dados específico, nem todas as funcionalidades de autenticação funcionarão em ambos os aplicativos:

  • Os usuários devem entrar por meio de apenas um dos aplicativos, seja o aplicativo ASP.NET ou o ASP.NET Core, seja qual for o banco de dados configurado para se trabalhar.
  • Ambos os aplicativos podem ver a identity e as declarações dos usuários.
  • Ambos os aplicativos podem desconectar o usuário.

Detalhes sobre como configurar o compartilhamento de cookies de autenticação entre aplicativos ASP.NET e ASP.NET Core estão disponíveis na documentação de compartilhamento de cookie. Os exemplos a seguir no repositório GitHub de adaptadores do System.Web demonstram a autenticação remota do aplicativo com a configuração de cookie compartilhada , permitindo que ambos os aplicativos entrem e saiam dos usuários:

O compartilhamento de autenticação será uma boa opção se as duas opções a seguir forem verdadeiras:

  • O aplicativo ASP.NET já está usando a autenticação Microsoft.Owin de cookie.
  • É possível atualizar o aplicativos ASP.NET e ASP.NET Core para usar as configurações de proteção de dados correspondentes. As configurações de proteção de dados compartilhadas correspondentes incluem um caminho de arquivo compartilhado, cache Redis ou Armazenamento de Blobs do Azure para armazenar chaves de proteção de dados.

Para outros cenários, a abordagem de autenticação remota descrita anteriormente neste documento é mais flexível e provavelmente é uma melhor opção.