Аутентификация и авторизация

Аутентификация и авторизация в 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

Эти протоколы обычно используются с внешними поставщиками удостоверений. Процесс аутентификации можно настроить в приложении прокси-сервера, и в результате будет создан cookie-файл аутентификации. Этот cookie-файл будет передан на сервер назначения как обычный заголовок запроса.

Windows, Negotiate, NTLM, Kerberos

Эти типы аутентификации часто привязаны к конкретному соединению. Они не поддерживаются как способ аутентификации пользователя на сервере назначения за прокси-сервером YARP (см. #166 . Их можно использовать для аутентификации входящего запроса к прокси-серверу, но эту информацию об удостоверении придётся передавать серверу назначения в другой форме. Их также можно использовать для аутентификации самого прокси-сервера перед серверами назначения, но только от имени собственной учётной записи прокси — олицетворение клиента не поддерживается.

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

Клиентские сертификаты — это функция TLS, согласуемая в рамках установления соединения. Дополнительные сведения приведены в этой документации

. Сертификат можно передать на сервер назначения в виде HTTP-заголовка,

используя преобразование ClientCert.

Замена типов аутентификации

Типы аутентификации, такие как Windows, которые не передаются на сервер назначения естественным образом, необходимо преобразовать на прокси-сервере в альтернативную форму. Например, можно создать JWT bearer-токен с информацией о пользователе и установить его в запросе прокси-сервера.

Такие замены можно выполнять с помощью пользовательских преобразований запросов. При достаточном интересе со стороны сообщества для конкретных сценариев можно разработать подробные примеры. Нам нужно больше отзывов от сообщества о том, как вы хотите преобразовывать и передавать информацию об удостоверении.