Udostępnij za pośrednictwem

Uwierzytelnianie zdalne

  • Artykuł

Funkcja zdalnego uwierzytelniania adapterów System.Web umożliwia aplikacji ASP.NET Core określenie tożsamości użytkownika (uwierzytelnianie żądania HTTP) przez odroczenie w aplikacji ASP.NET. Włączenie funkcji dodaje punkt końcowy do aplikacji ASP.NET, która zwraca serializowaną ClaimsPrincipal reprezentację uwierzytelnionego użytkownika dla wszystkich żądań wysyłanych do punktu końcowego. Następnie aplikacja ASP.NET Core rejestruje niestandardową procedurę obsługi uwierzytelniania, która (w przypadku punktów końcowych z włączonym uwierzytelnianiem zdalnym) określa tożsamość użytkownika, wywołując ten punkt końcowy w aplikacji ASP.NET i przekazując wybrane nagłówki i cookies z oryginalnego żądania odebranego przez aplikację ASP.NET Core.

Konfigurowanie

Istnieje kilka drobnych zmian kodu potrzebnych do włączenia uwierzytelniania zdalnego w rozwiązaniu, które jest już skonfigurowane zgodnie z wprowadzeniem.

Najpierw postępuj zgodnie z instrukcjami konfiguracji aplikacji zdalnej, aby połączyć aplikacje ASP.NET Core i ASP.NET. Następnie istnieje tylko kilka dodatkowych metod rozszerzenia do wywołania w celu włączenia uwierzytelniania zdalnej aplikacji.

konfiguracja aplikacji ASP.NET

Aby dodać punkt końcowy uwierzytelniania, należy skonfigurować aplikację ASP.NET. Dodanie punktu końcowego uwierzytelniania odbywa się przez wywołanie AddAuthenticationServer metody rozszerzenia w celu skonfigurowania modułu HTTP, który obserwuje żądania do punktu końcowego uwierzytelniania. Należy pamiętać, że scenariusze uwierzytelniania zdalnego zwykle wymagają również dodania obsługi serwera proxy, dzięki czemu wszystkie przekierowania powiązane z uwierzytelnianiem są prawidłowo kierowane do aplikacji ASP.NET Core, a nie do ASP.NET.

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

konfiguracja aplikacji ASP.NET Core

Następnie należy skonfigurować aplikację ASP.NET Core, aby umożliwić obsługę uwierzytelniania, która będzie uwierzytelniać użytkowników, wysyłając żądanie HTTP do aplikacji ASP.NET. Ponownie jest to wykonywane przez wywołanie AddAuthenticationClient podczas rejestrowania usług System.Web adapterów:

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

Wartość logiczna przekazywana do wywołania AddAuthenticationClient określa, czy uwierzytelnianie zdalne aplikacji powinno być domyślnym schematem uwierzytelniania. Przekazywanie true spowoduje uwierzytelnienie użytkownika za pośrednictwem zdalnego uwierzytelniania aplikacji dla wszystkich żądań, natomiast przekazywanie false oznacza, że użytkownik zostanie uwierzytelniony tylko przy użyciu zdalnego uwierzytelniania aplikacji, jeśli schemat aplikacji zdalnej jest specjalnie żądany ( [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] na przykład za pomocą kontrolera lub metody akcji). Przekazywanie wartości false dla tego parametru ma zaletę tylko przesyłania żądań HTTP do oryginalnej aplikacji ASP.NET na potrzeby uwierzytelniania punktów końcowych wymagających zdalnego uwierzytelniania aplikacji, ale ma wadę wymagania dodawania adnotacji do wszystkich takich punktów końcowych, aby wskazać, że będą używać zdalnego uwierzytelniania aplikacji.

Oprócz wymaganej wartości logicznej można przekazać opcjonalne wywołanie zwrotne w celu AddAuthenticationClient zmodyfikowania innych aspektów zachowania procesu uwierzytelniania zdalnego:

  • RequestHeadersToForward: Ta właściwość zawiera nagłówki, które powinny być przekazywane z żądania podczas wywoływania interfejsu API uwierzytelniania. Domyślnie jedynymi nagłówkami przekazywanymi są Authorization i Cookie. Dodatkowe nagłówki można przekazywać dalej, dodając je do tej listy. Alternatywnie, jeśli lista zostanie wyczyszczone (aby nie określono żadnych nagłówków), wszystkie nagłówki zostaną przekazane.
  • ResponseHeadersToForward: Ta właściwość wyświetla nagłówki odpowiedzi, które powinny być propagowane z powrotem z żądania uwierzytelniania do oryginalnego wywołania, które monituje uwierzytelnianie w scenariuszach, w których tożsamość jest kwestionowana. Domyślnie obejmuje Locationto nagłówki , Set-Cookiei WWW-Authenticate .
  • AuthenticationEndpointPath: punkt końcowy w aplikacji ASP.NET, w której powinny zostać wykonane żądania uwierzytelniania. Ta wartość domyślna /systemweb-adapters/authenticate to i musi być zgodna z punktem końcowym określonym w konfiguracji punktu końcowego uwierzytelniania ASP.NET.

Na koniec, jeśli aplikacja ASP.NET Core nie zawierała wcześniej oprogramowania pośredniczącego uwierzytelniania, należy je włączyć (po routingu oprogramowania pośredniczącego, ale przed oprogramowaniem pośredniczącym autoryzacji):

app.UseAuthentication();

Zaprojektuj

  1. Gdy żądania są przetwarzane przez aplikację ASP.NET Core, jeśli uwierzytelnianie zdalne aplikacji jest schematem domyślnym lub określonym przez punkt końcowy żądania, RemoteAuthenticationAuthHandler program podejmie próbę uwierzytelnienia użytkownika.
    1. Procedura obsługi wyśle żądanie HTTP do punktu końcowego uwierzytelnienia aplikacji ASP.NET. Skopiuje skonfigurowane nagłówki z bieżącego żądania do tego nowego w celu przekazania danych odpowiednich do uwierzytelniania. Jak wspomniano powyżej, domyślne zachowanie polega na skopiowaniu Authorize nagłówków i .Cookie Nagłówek klucza interfejsu API jest również dodawany do celów zabezpieczeń.
  2. Aplikacja ASP.NET będzie obsługiwać żądania wysyłane do punktu końcowego uwierzytelniania. Tak długo, jak klucze interfejsu API są zgodne, aplikacja ASP.NET zwróci serializacji bieżącego użytkownika ClaimsPrincipal do treści odpowiedzi lub zwróci kod stanu HTTP (na przykład 401 lub 302) i nagłówki odpowiedzi wskazujące niepowodzenie.
  3. Gdy aplikacja RemoteAuthenticationAuthHandler ASP.NET Core odbiera odpowiedź z aplikacji ASP.NET:
    1. Jeśli funkcja ClaimsPrincipal została pomyślnie zwrócona, program obsługi uwierzytelniania zdeserializuje go i użyje go jako tożsamości bieżącego użytkownika.
    2. Jeśli żądanie ClaimsPrincipal nie zostało pomyślnie zwrócone, program obsługi zapisze wynik i jeśli zostanie zakwestionowane uwierzytelnianie (ponieważ użytkownik uzyskuje dostęp do chronionego zasobu, na przykład), odpowiedź żądania zostanie zaktualizowana przy użyciu kodu stanu i wybranych nagłówków odpowiedzi z odpowiedzi z punktu końcowego uwierzytelniania. Dzięki temu odpowiedzi na wyzwania (na przykład przekierowania do strony logowania) mogą być propagowane do użytkowników końcowych.
      1. Ponieważ wyniki z punktu końcowego uwierzytelniania aplikacji ASP.NET mogą zawierać dane specyficzne dla tego punktu końcowego, użytkownicy mogą rejestrować IRemoteAuthenticationResultProcessor implementacje w aplikacji ASP.NET Core, która będzie uruchamiana na wszystkich wynikach uwierzytelniania przed ich użyciem. Na przykład jedna wbudowana IRemoteAuthenticationResultProcessorRedirectUrlProcessor funkcja wyszukuje Location nagłówki odpowiedzi zwrócone z punktu końcowego uwierzytelniania i zapewnia przekierowanie z powrotem do hosta aplikacji ASP.NET Core, a nie bezpośrednio ASP.NET aplikacji.

Znane ograniczenia

To podejście do uwierzytelniania zdalnego ma kilka znanych ograniczeń:

  1. Ponieważ uwierzytelnianie systemu Windows zależy od dojścia do tożsamości systemu Windows, uwierzytelnianie systemu Windows nie jest obsługiwane przez tę funkcję. Planowane jest przyszłe prace w celu zbadania, jak może działać współużytkowane uwierzytelnianie systemu Windows. Aby uzyskać więcej informacji, zobacz dotnet/systemweb-adapters#246 .
  2. Ta funkcja umożliwia aplikacji ASP.NET Core korzystanie z tożsamości uwierzytelnionej przez aplikację ASP.NET, ale wszystkie akcje związane z użytkownikami (logowanie, wylogowanie itp.) nadal muszą być kierowane przez aplikację ASP.NET.

Alternatywy

Jeśli uwierzytelnianie w aplikacji ASP.NET odbywa się przy użyciu Microsoft.OwinCookie oprogramowania pośredniczącego uwierzytelniania, alternatywnym rozwiązaniem do udostępniania tożsamości jest skonfigurowanie ASP.NET i ASP.NET Core aplikacji, aby mogły udostępniać uwierzytelnianie cookie. Udostępnianie uwierzytelniania cookie umożliwia:

  • Obie aplikacje do określenia tożsamości użytkownika z tego samego cookieelementu .
  • Logowanie lub wylogowanie się z jednej aplikacji powoduje zalogowanie użytkownika do innej aplikacji lub poza nie.

Należy pamiętać, że ponieważ logowanie zwykle zależy od określonej bazy danych, nie wszystkie funkcje uwierzytelniania będą działać w obu aplikacjach:

  • Użytkownicy powinni logować się tylko za pomocą jednej z aplikacji — ASP.NET lub ASP.NET Core — niezależnie od tego, z którą bazą danych jest skonfigurowana do pracy.
  • Obie aplikacje są w stanie zobaczyć tożsamość i oświadczenia użytkowników.
  • Obie aplikacje mogą wylogować użytkownika.

Szczegółowe informacje na temat konfigurowania uwierzytelniania cookieudostępniania między aplikacjami ASP.NET i ASP.NET Core są dostępne w cookie dokumentacji udostępniania. W poniższych przykładach w repozytorium GitHub adapterów System.Web pokazano zdalne uwierzytelnianie aplikacji z udostępnioną cookie konfiguracją umożliwiającą logowanie użytkowników do i na wylogowywanie użytkowników:

Uwierzytelnianie do udostępniania jest dobrym rozwiązaniem, jeśli oba te elementy są spełnione:

  • Aplikacja ASP.NET już używa Microsoft.Owincookie uwierzytelniania.
  • Można zaktualizować aplikację ASP.NET i aplikacje ASP.NET Core w celu używania pasujących ustawień ochrony danych. Zgodne ustawienia ochrony danych udostępnionych obejmują udostępnioną ścieżkę pliku, pamięć podręczną Redis cache lub usługę Azure Blob Storage do przechowywania kluczy ochrony danych.

W przypadku innych scenariuszy podejście do uwierzytelniania zdalnego opisane wcześniej w tym dokumentie jest bardziej elastyczne i prawdopodobnie lepiej pasuje.