Udostępnij za pośrednictwem

Uwierzytelnianie i autoryzacja YARP

Wprowadzenie

Zwrotny serwer proxy może służyć do uwierzytelniania i autoryzacji żądań, zanim zostaną one przekazane do serwerów docelowych. Może to zmniejszyć obciążenie serwerów docelowych, dodać warstwę ochrony i zapewnić zaimplementowanie spójnych zasad w aplikacjach.

Ustawienia domyślne

Uwierzytelnianie lub autoryzacja nie są wykonywane na żądaniach, chyba że włączono je w konfiguracji trasy lub aplikacji.

Konfiguracja

Zasady autoryzacji można określić na trasę za pośrednictwem routeConfig.AuthorizationPolicy i można je powiązać z Routes sekcjami pliku konfiguracji. Podobnie jak w przypadku innych właściwości trasy, można je modyfikować i ładować ponownie bez ponownego uruchamiania serwera proxy. Nazwy zasad są niewrażliwe na wielkość liter.

Przykład:

{
  "ReverseProxy": {
    "Routes": {
      "route1" : {
        "ClusterId": "cluster1",
        "AuthorizationPolicy": "customPolicy",
        "Match": {
          "Hosts": [ "localhost" ]
        }
      }
    },
    "Clusters": {
      "cluster1": {
        "Destinations": {
          "cluster1/destination1": {
            "Address": "https://localhost:10001/"
          }
        }
      }
    }
  }
}

Zasady autoryzacji to pojęcie ASP.NET Core używane przez serwer proxy. Proxy zapewnia powyższą konfigurację, aby określić zasady dla każdej trasy, a pozostałe są obsługiwane przez istniejące składniki uwierzytelniania i autoryzacji ASP.NET Core.

Zasady autoryzacji można skonfigurować w aplikacji w następujący sposób:

services.AddAuthorization(options =>
{
    options.AddPolicy("customPolicy", policy =>
        policy.RequireAuthenticatedUser());
});

W pliku Program.cs dodaj oprogramowanie pośredniczące dla autoryzacji i uwierzytelniania.

app.UseAuthentication();
app.UseAuthorization();

app.MapReverseProxy();

Zobacz dokumentację uwierzytelniania , aby skonfigurować preferowany rodzaj uwierzytelniania.

Wartości specjalne:

Oprócz niestandardowych nazw zasad istnieją dwie specjalne wartości, które można określić w parametrze autoryzacji trasy: default i anonymous. ASP.NET Core ma również ustawienie FallbackPolicy, które ma zastosowanie do tras, które nie określają zasad.

DefaultPolicy

Określenie wartości default w parametrze autoryzacji trasy oznacza, że trasa będzie używać zasad zdefiniowanych w polach AuthorizationOptions.DefaultPolicy. Te zasady są wstępnie skonfigurowane tak, aby wymagały uwierzytelnionych użytkowników.

Anonim

Określenie wartości anonymous w parametrze autoryzacji trasy oznacza, że trasa nie będzie wymagać autoryzacji niezależnie od jakiejkolwiek innej konfiguracji w aplikacji, takiej jak FallbackPolicy.

FallbackPolicy

AuthorizationOptions.FallbackPolicy to polityka, która będzie używana dla dowolnego żądania lub trasy, które nie zostały skonfigurowane z polityką. FallbackPolicy nie ma wartości domyślnie, każde żądanie będzie dozwolone.

Przepływanie poświadczeń

Nawet po autoryzowanym żądaniu na serwerze proxy serwer docelowy może nadal wiedzieć, kto jest użytkownikiem (uwierzytelnianie) i co może zrobić (autoryzacja). Sposób przepływu tych informacji zależy od typu używanego uwierzytelniania.

Te typy uwierzytelniania domyślnie przekazują swoje wartości w nagłówkach żądań i będą one domyślnie przepływać do serwera docelowego. Ten serwer będzie nadal musiał zweryfikować i zinterpretować te wartości, co powoduje podwójną pracę.

OAuth2, OpenIdConnect, WsFederation

Te protokoły są często używane z dostawcami tożsamości zdalnych. Proces uwierzytelniania można skonfigurować w aplikacji serwera proxy i spowoduje uwierzytelnienie cookie. Będzie to cookie przepływać do serwera docelowego jako normalny nagłówek żądania.

Windows, Negotiate, NTLM, Kerberos

Te typy uwierzytelniania są często powiązane z określonym połączeniem. Nie są one obsługiwane jako sposób uwierzytelniania użytkownika na serwerze docelowym za serwerem proxy YARP (zobacz nr 166. Mogą służyć do uwierzytelniania żądania przychodzącego na serwerze proxy, ale informacje o tożsamości muszą być przekazywane do serwera docelowego w innej formie. Mogą być one również używane do uwierzytelniania serwera proxy względem serwerów docelowych, ale tylko jako własny użytkownik serwera proxy; udawanie klienta nie jest obsługiwane.

Certyfikaty klienta

Certyfikaty klienta są funkcją protokołu TLS i są negocjowane w ramach połączenia. Aby uzyskać dodatkowe informacje, zobacz te dokumenty . Certyfikat można przekazać do serwera docelowego jako nagłówek HTTP przy użyciu przekształcenia ClientCert .

Zamienianie typów uwierzytelniania

Typy uwierzytelniania, takie jak Windows, które nie przepływają naturalnie do serwera docelowego, muszą zostać przekonwertowane w proxy na alternatywną formę. Na przykład token elementu nośnego JWT można utworzyć przy użyciu informacji o użytkowniku i ustawić go na żądanie serwera proxy.

Te zamiany można wykonać przy użyciu niestandardowych przekształceń żądań. Szczegółowe przykłady można opracowywać dla konkretnych scenariuszy, jeśli jest wystarczająca ilość zainteresowania społeczności. Potrzebujemy więcej opinii społeczności na temat sposobu konwertowania i przepływu informacji o tożsamości.