Поделиться через


Удаленная проверка подлинности

Функция удаленной проверки подлинности системных веб-адаптеров позволяет приложению ASP.NET Core определить пользователя identity (аутентификацию HTTP-запроса), отложив приложение ASP.NET. Включение функции добавляет конечную точку в приложение ASP.NET, которое возвращает сериализованную ClaimsPrincipal , представляющую пользователя, прошедшего проверку подлинности, для любых запросов, сделанных в конечную точку. Затем приложение ASP.NET Core регистрирует настраиваемый обработчик проверки подлинности, который будет (для конечных точек с включенной удаленной проверкой подлинности) определять пользователя identity , вызывая такую конечную точку в приложении ASP.NET и передавая выбранные заголовки и файлы cookie из исходного запроса, полученного приложением ASP.NET Core.

Настройка

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

Сначала следуйте инструкциям по настройке удаленного приложения, чтобы подключить приложения ASP.NET Core и ASP.NET. Затем есть несколько дополнительных методов расширения для вызова для включения проверки подлинности удаленного приложения.

ASP.NET конфигурации приложения

Приложение ASP.NET необходимо настроить для добавления конечной точки проверки подлинности. Добавление конечной точки проверки подлинности выполняется путем вызова AddAuthenticationServer метода расширения для настройки модуля HTTP, который проверяет запросы к конечной точке проверки подлинности. Обратите внимание, что сценарии удаленной проверки подлинности обычно хотят добавить поддержку прокси-сервера, чтобы все связанные с проверкой подлинности правильно перенаправлялись в приложение ASP.NET Core, а не ASP.NET.

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

конфигурация приложения ASP.NET Core

Затем необходимо настроить приложение ASP.NET Core, чтобы включить обработчик проверки подлинности, который будет проходить проверку подлинности пользователей, выполняя HTTP-запрос к приложению ASP.NET. Опять же, это делается путем вызова AddAuthenticationClient при регистрации служб System.Web adapters:

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

Логическое значение, переданное вызову AddAuthenticationClient , указывает, должна ли удаленная проверка подлинности приложения быть схемой проверки подлинности по умолчанию. Передача true приведет к тому, что пользователь будет проходить проверку подлинности с помощью удаленной проверки подлинности приложения для всех запросов, в то время как передача false означает, что пользователь будет проходить проверку подлинности только с помощью удаленной проверки подлинности приложения, если схема удаленного приложения запрашивается специально (например, с [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] контроллером или методом действия). Передача false для этого параметра имеет преимущество только отправки HTTP-запросов к исходному приложению ASP.NET для проверки подлинности для конечных точек, требующих удаленной проверки подлинности приложения, но имеет недостаток, требующий аннотирования всех таких конечных точек, чтобы указать, что они будут использовать удаленную проверку подлинности приложений.

В дополнение к логическому запросу можно передать необязательный обратный вызов, чтобы AddAuthenticationClient изменить некоторые другие аспекты поведения процесса удаленной проверки подлинности:

  • RequestHeadersToForward: это свойство содержит заголовки, которые следует перенаправить из запроса при вызове API проверки подлинности. По умолчанию перенаправляются Authorization Cookieтолько заголовки. Дополнительные заголовки можно перенаправить, добавив их в этот список. Кроме того, если список очищается (так что заголовки не указаны), все заголовки будут перенаправляются.
  • ResponseHeadersToForward: это свойство содержит заголовки ответов, которые должны распространяться обратно из запроса проверки подлинности на исходный вызов, который запросил проверку подлинности в сценариях, где identity возникает проблема. По умолчанию это включает Locationи Set-CookieWWW-Authenticate заголовки.
  • AuthenticationEndpointPath: конечная точка в приложении ASP.NET, где должны выполняться запросы проверки подлинности. Это значение /systemweb-adapters/authenticate по умолчанию и должно соответствовать конечной точке, указанной в конфигурации конечной точки проверки подлинности ASP.NET.

Наконец, если приложение ASP.NET Core ранее не включало ПО промежуточного слоя проверки подлинности, необходимо включить (после по промежуточного слоя маршрутизации, но до по промежуточного слоя авторизации):

app.UseAuthentication();

Проект

  1. Когда запросы обрабатываются приложением ASP.NET Core, если удаленная проверка подлинности приложений является схемой по умолчанию или указана конечной точкой запроса, RemoteAuthenticationAuthHandler будет пытаться пройти проверку подлинности пользователя.
    1. Обработчик выполнит HTTP-запрос к конечной точке проверки подлинности приложения ASP.NET. Он будет копировать настроенные заголовки из текущего запроса на новый, чтобы перенаправить данные, относящиеся к проверке подлинности. Как упоминалось выше, поведение по умолчанию заключается в копировании Authorize заголовков и Cookie заголовков. Заголовок ключа API также добавляется в целях безопасности.
  2. Приложение ASP.NET будет обслуживать запросы, отправленные в конечную точку проверки подлинности. Если ключи API совпадают, приложение ASP.NET вернет сериализованный текущий пользователь ClaimsPrincipal в текст ответа или возвращает код состояния HTTP (например, 401 или 302) и заголовки ответов, указывающие на сбой.
  3. Когда приложение ASP.NET Core получает ответ от приложения RemoteAuthenticationAuthHandler ASP.NET:
    1. Если параметр ClaimsPrincipal был успешно возвращен, обработчик проверки подлинности десериализирует его и будет использовать его в качестве текущего пользователя identity.
    2. Если утверждение ClaimsPrincipal не было успешно возвращено, обработчик будет хранить результат и если проверка подлинности оспаривается (так как пользователь обращается к защищенному ресурсу, например), ответ запроса будет обновлен с кодом состояния и выбранными заголовками ответов из ответа от конечной точки проверки подлинности. Это позволяет ответы на вызовы (например, перенаправления на страницу входа) распространяться на конечных пользователей.
      1. Так как результаты из конечной точки проверки подлинности приложения ASP.NET могут включать данные, относящиеся к этой конечной точке, пользователи могут регистрировать IRemoteAuthenticationResultProcessor реализации в приложении ASP.NET Core, которое будет выполняться на всех результатах проверки подлинности перед их использованием. Например, одна встроенная IRemoteAuthenticationResultProcessorRedirectUrlProcessor это поиск Location заголовков ответов, возвращаемых из конечной точки проверки подлинности, и гарантирует, что они перенаправляются обратно на узел приложения ASP.NET Core, а не ASP.NET приложения напрямую.

Известные ограничения

Этот подход к удаленной проверке подлинности имеет несколько известных ограничений:

  1. Так как проверка подлинности Windows зависит от дескриптора Windowsidentity, проверка подлинности Windows не поддерживается этой функцией. В будущем планируется изучить, как могут работать общие проверка подлинности Windows. Дополнительные сведения см. в dotnet/systemweb-adapters#246 .
  2. Эта функция позволяет приложению ASP.NET Core использовать identity проверку подлинности приложения ASP.NET, но все действия, связанные с пользователями (вход, отключение входа и т. д.), по-прежнему необходимо направлять через приложение ASP.NET.

Альтернативные варианты

Если проверка подлинности в приложении ASP.NET выполняется с помощью Microsoft.OwinCookie по промежуточного слоя проверки подлинности, альтернативным решением для общего доступа identity является настройка ASP.NET и ASP.NET основных приложений, чтобы они могли совместно использовать проверку подлинности cookie. Предоставление общего доступа к проверке подлинности cookie включает:

  • Оба приложения, чтобы определить пользователя identity из одного и того же cookie.
  • Вход или выход из одного приложения входит в другое приложение или выходит из него.

Обратите внимание, что поскольку вход обычно зависит от определенной базы данных, не все функции проверки подлинности будут работать в обоих приложениях:

  • Пользователи должны войти только через одно из приложений, ASP.NET или ASP.NET Core, независимо от того, с какой базой данных настроена работа.
  • Оба приложения могут видеть утверждения пользователей identity и пользователей.
  • Оба приложения могут выйти из него.

Сведения о настройке файлов cookie проверки подлинности для общего доступа между ASP.NET и ASP.NET приложениями Core доступны в cookie документации по совместному использованию. В следующих примерах в репозитории GitHub system.Web adapters демонстрируется проверка подлинности удаленного приложения с общей cookie конфигурацией, что позволяет обоим приложениям входить и выходить:

Общий доступ к проверке подлинности является хорошим вариантом, если оба следующих значения имеют значение true:

  • Приложение ASP.NET уже использует Microsoft.Owincookie проверку подлинности.
  • Можно обновить приложение ASP.NET и приложения ASP.NET Core, чтобы использовать соответствующие параметры защиты данных. Соответствующие параметры защиты данных включают общий путь к файлу, кэш Redis или Хранилище BLOB-объектов Azure для хранения ключей защиты данных.

В других сценариях подход удаленной проверки подлинности, описанный ранее в этом документе, является более гибким и, вероятно, лучше подходит.