Partilhar via

Autenticação remota

  • Artigo

O recurso de autenticação remota dos adaptadores System.Web permite que um aplicativo ASP.NET Core determine a identidade de um usuário (autentique uma solicitação HTTP) delegando a autenticação para um aplicativo ASP.NET. Ao habilitar o recurso, é adicionado um ponto de extremidade ao aplicativo ASP.NET que retorna uma ClaimsPrincipal serializada, representando o usuário autenticado para todas as solicitações ao ponto de extremidade. O aplicativo ASP.NET Core, então, registra um manipulador de autenticação personalizado que determinará (para pontos de extremidade com autenticação remota habilitada) a identidade 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 ASP.NET Core.

Configuração

Há apenas algumas pequenas alterações de código necessárias para ativar a autenticação remota numa solução que já está configurada de acordo com o Primeiros Passos.

Primeiro, siga as instruções da configuração da aplicação remota para conectar as aplicações ASP.NET Core e ASP.NET. Em seguida, há apenas alguns métodos adicionais de extensão a chamar para habilitar a autenticação remota da aplicação.

ASP.NET configuração do aplicativo

A aplicação ASP.NET precisa ser configurada para adicionar o endpoint 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 solicitações para o ponto de extremidade de autenticação. Observe que os cenários de autenticação remota normalmente também desejam adicionar suporte a proxy, para que qualquer redirecionamento relacionado à autenticação seja encaminhado corretamente para o aplicativo ASP.NET Core em vez do aplicativo 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 manipulador 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 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 booleano que é passado para a chamada AddAuthenticationClient especifica se a autenticação de aplicativo remoto deve ser o esquema de autenticação padrão. Passar true fará com que o usuário seja autenticado por meio de autenticação de aplicativo remoto para todas as solicitações, enquanto passar false significa que o usuário só será autenticado com autenticação de aplicativo remoto se o esquema de aplicativo remoto for especificamente solicitado (com [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] em um controlador ou método de ação, por exemplo). Passar false para este parâmetro tem a vantagem de fazer apenas solicitações HTTP do aplicativo ASP.NET original para autenticação em pontos de extremidade que requerem autenticação por aplicação remota, mas tem a desvantagem de exigir a anotação de todos esses pontos de extremidade para indicar que eles usarão autenticação remota.

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

  • RequestHeadersToForward: Esta propriedade contém cabeçalhos que devem ser encaminhados de um pedido ao chamar a API de autenticação. Por padrão, os únicos cabeçalhos encaminhados são Authorization e Cookie. Podem ser encaminhados cabeçalhos adicionais ao adicioná-los a esta lista. Como alternativa, se a lista for limpa (de modo que nenhum cabeçalho seja especificado), todos os cabeçalhos serão encaminhados.
  • ResponseHeadersToForward: Esta propriedade lista cabeçalhos de resposta que devem ser propagados de volta da solicitação de autenticação para a chamada original que solicitou autenticação em cenários onde a identidade é desafiada. Por padrão, isso inclui cabeçalhos Location, Set-Cookiee WWW-Authenticate.
  • AuthenticationEndpointPath: O ponto de extremidade no aplicativo ASP.NET onde as solicitações de autenticação devem ser feitas. O padrão é /systemweb-adapters/authenticate e deve corresponder ao ponto de extremidade especificado na configuração do ponto de extremidade de autenticação ASP.NET.

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

app.UseAuthentication();

Desenho

  1. Quando as solicitações são processadas pelo aplicativo ASP.NET Core, se a autenticação remota do aplicativo for o esquema padrão ou especificado pelo ponto de extremidade da solicitação, o RemoteAuthenticationAuthHandler tentará autenticar o usuário.
    1. O manipulador 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 esta nova, a fim de encaminhar dados relevantes para auth. Como mencionado acima, o comportamento padrão é copiar os cabeçalhos Authorize e Cookie. O cabeçalho da chave da API também é adicionado para fins de segurança.
  2. A aplicação ASP.NET irá atender as solicitações enviadas para o endpoint de autenticação. Contanto que as chaves API sejam iguais, a aplicação ASP.NET retornará o ClaimsPrincipal do utilizador atual serializado no corpo da resposta ou retornará um código de status HTTP (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. Caso um ClaimsPrincipal seja retornado com sucesso, o manipulador de autenticação irá desserializá-lo e utilizá-lo como identidade do utilizador atual.
    2. Se um ClaimsPrincipal não foi retornado com êxito, o manipulador 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 de status e cabeçalhos de resposta selecionados da resposta do ponto de extremidade autenticado. Isso permite que respostas de desafio (como redirecionamentos para uma página de login) 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 desse ponto, os utilizadores podem registar implementações IRemoteAuthenticationResultProcessor no aplicativo ASP.NET Core, que serão executadas em quaisquer resultados de autenticação antes de serem utilizados. Por exemplo, um IRemoteAuthenticationResultProcessor integrado é 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 da aplicação ASP.NET Core e não diretamente para a aplicação ASP.NET.

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 identidade do Windows, a autenticação do Windows não é suportada por esse recurso. Trabalhos futuros estão planejados para explorar como a autenticação compartilhada do Windows pode funcionar. Consulte dotnet/systemweb-adapters#246 para obter mais informações.
  2. Esse recurso permite que o aplicativo ASP.NET Core use uma identidade autenticada pelo aplicativo ASP.NET, mas todas as ações relacionadas aos usuários (logon, logoff, etc.) ainda precisam ser roteadas pelo aplicativo ASP.NET.

Alternativas

Se a autenticação na aplicação ASP.NET for feita usando Microsoft.OwinCookie Middleware de Autenticação, uma solução alternativa para o compartilhamento de identidade é configurar as aplicações ASP.NET e ASP.NET Core de forma a conseguirem partilhar um cookiede autenticação. O compartilhamento de um cookie de autenticação permite:

  • Ambas as aplicações para determinar a identidade do utilizador a partir do mesmo cookie.
  • Entrar ou sair de um aplicativo faz com que o usuário entre ou saia do outro aplicativo.

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

  • Os utilizadores devem entrar através de apenas uma das aplicações, seja a aplicação ASP.NET ou a aplicação ASP.NET Core, consoante a configuração do banco de dados com que a aplicação está preparada para trabalhar.
  • Ambos os aplicativos são capazes de ver a identidade e as declarações dos usuários.
  • Ambos os aplicativos são capazes de desconectar o usuário.

Detalhes sobre como configurar cookies de autenticação para partilha entre aplicações ASP.NET e ASP.NET Core estão disponíveis na documentação sobre partilha cookie. Os exemplos a seguir no repositório System.Web adaptadores GitHub demonstram a autenticação de aplicativos remotos com configuração de cookie compartilhada, permitindo que ambas as aplicações autentiquem a entrada e saída dos utilizadores.

O compartilhamento de autenticação é uma boa opção se ambas as seguintes condições forem verdadeiras:

  • O aplicativo ASP.NET já está usando a autenticação Microsoft.Owincookie.
  • É possível atualizar o aplicativo ASP.NET e os aplicativos 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 Blob 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 é mais adequada.