Удостоверяване и оторизация

Удостоверяване и оторизация в YARP

Въведение

Обратният прокси сървър може да се използва за удостоверяване и оторизация на заявките, преди те да бъдат препратени към дестинациите. Това може да намали натоварването на дестинациите, да добави допълнителен слой защита и да гарантира последователно прилагане на политиките във всички ваши приложения.

Стойности по подразбиране

Върху заявките не се извършва удостоверяване или оторизация, освен ако това не е разрешено в конфигурацията на маршрута или на приложението.

Конфигурация

Политиките за оторизация могат да бъдат зададени за всеки маршрут поотделно чрез RouteConfig.AuthorizationPolicy и могат да бъдат обвързани от секциите Routes на конфигурационния файл. Както при другите свойства на маршрута, това може да бъде променяно и презареждано без рестартиране на прокси сървъра. Имената на политиките не са чувствителни към главни и малки букви.

Пример:

JSON{
   "ReverseProxy": {
      "Routes": {
          "route1" : {
             "ClusterId": "cluster1",
             "AuthorizationPolicy": "customPolicy",
             "Match": {
                "Hosts": [ "localhost" ]
             }
          }
      },
      "Clusters": {
          "cluster1": {
             "Destinations": {
                "cluster1/destination1": {
                    "Address": "https://localhost:10001/"
                }
             }
          }
      }
             }
          }
Authorization policies are an ASP.NET Core concept that the proxy utilizes. The proxy provides
the above configuration to specify a policy per route and the rest is handled by existing
ASP.NET Core authentication and authorization components.
Authorization policies can be configured in the application as follows:
   services.AddAuthorization(options =>
   {
          options.AddPolicy("customPolicy", policy =>
                 policy.RequireAuthenticatedUser());
   });
In Program.cs add the Authorization and Authentication middleware.
   app.UseAuthentication();
   app.UseAuthorization();
   app.MapReverseProxy();
See the Authentication docs for setting up your preferred kind of authentication.
Special values:
In addition to custom policy names, there are two special values that can be specified in a
route's authorization parameter: default and anonymous . ASP.NET Core also has a
FallbackPolicy setting that applies to routes that do not specify a policy.

DefaultPolicy

Задаването на стойност default в параметъра за оторизация на даден маршрут означава, че този маршрут ще използва политиката, дефинирана в AuthorizationOptions.DefaultPolicy. Тази политика е предварително конфигурирана да изисква удостоверени потребители.

Anonymous

Задаването на стойност anonymous в параметъра за оторизация на даден маршрут означава, че този маршрут няма да

изисква оторизация, независимо от друга конфигурация в приложението, като например

FallbackPolicy.

FallbackPolicy

AuthorizationOptions.FallbackPolicy е политиката, която ще се използва за всяка заявка или маршрут, за които не е конфигурирана политика. FallbackPolicy няма стойност по подразбиране, така че всички заявки ще бъдат разрешени.

Предаване на удостоверителни данни

Дори след като дадена заявка вече е била оторизирана в прокси сървъра, дестинацията може все още да се нуждае да знае кой е потребителят (удостоверяване) и какво му е позволено да прави (оторизация). Начинът, по който предавате тази информация, зависи от вида на използваното удостоверяване.

Cookie, bearer, API ключове

Тези типове удостоверяване вече предават стойностите си в заглавните части на заявката и по подразбиране те се прехвърлят към дестинацията. Тя все пак ще трябва да провери и интерпретира тези стойности, което води до известно дублиране на работата.

OAuth2, OpenIdConnect, WsFederation

Тези протоколи обикновено се използват с отдалечени доставчици на идентичност. Процесът на удостоверяване може да бъде конфигуриран в прокси приложението и води до създаването на бисквитка за удостоверяване. Тази бисквитка ще бъде прехвърлена към дестинацията като обикновена заглавна част на заявката.

Windows, Negotiate, NTLM, Kerberos

Тези типове удостоверяване често са обвързани с конкретна връзка. Те не се поддържат като средство за удостоверяване на потребител в дестинация зад YARP прокси сървъра (вижте #166). Те могат да се използват за удостоверяване на входяща заявка към прокси сървъра, но тази информация за идентичността ще трябва да бъде предадена на дестинацията по друг начин. Освен това могат да се използват за удостоверяване на прокси сървъра пред дестинациите, но само от името на собствения потребител на прокси сървъра — представянето от името на клиента (impersonation) не се поддържа.

Клиентски сертификати

Клиентските сертификати са функция на TLS и се договарят като част от установяването на връзката. Вижте тази документация

за допълнителна информация. Сертификатът може да бъде препратен към дестинацията като

HTTP заглавна част чрез трансформацията ClientCert.

Смяна на типовете удостоверяване

Типове удостоверяване като Windows, които не се предават естествено към дестинацията, трябва да бъдат преобразувани в прокси сървъра в алтернативна форма. Например може да се създаде JWT bearer токен с информацията за потребителя и да се зададе в заявката на прокси сървъра.

Тези замени могат да се извършват чрез персонализирани трансформации на заявки. При достатъчен интерес от общността могат да бъдат разработени подробни примери за конкретни сценарии. Имаме нужда от повече обратна връзка от общността относно това как искате да преобразувате и предавате информацията за идентичност.