ClaimsAuthenticationManager против IAuthenticationFilter и OWIN Forms Authentication

.NET 4.5, MVC 5: ClaimsAuthenticationManager, IAuthenticationFilter, OWIN Forms Authentication и ClaimsPrincipals являются новыми, поскольку я последний раз коснулся функций проверки подлинности моего сайта. Я обнаружил недостаток ясности во всех документах, которые говорят, что то или это правильно. Я даже не могу сказать, какие функции являются взаимоисключающими.

В этом документе говорится, что старый ASP.NET FormsAuthenticationModule не поддерживает претензии, но новый OWIN не поддерживает cookieless. Тем не менее, у меня возникает ощущение, что OWIN предназначен для продвижения вперед?

  • Указывает ли дорожная карта продукта, какой метод является продвижением для веб-приложений?
  • Является ли ClaimsAuthenticationManager синонимом OWIN Forms Authentication для веб-приложений?
  • Являются ли атрибуты ClaimsAuthenticationManager и глобальным IAuthenticationFilter взаимоисключающими?

Было бы полезно нажать в правильном направлении, мой мозг жарится на этом.

ОТВЕТЫ

Ответ 1

IAuthenticationFilter

Ранее в MVC IAuthorizationFilter было обычным местом для выполнения пользовательской аутентификации. Обоснование этого фильтра можно увидеть в сценарии, в котором приложение имеет две спецификации авторизации и только одну спецификацию аутентификации. Два варианта: добавление спецификации аутентификации к одной произвольной процедуре авторизации и создание всех трех этих спецификаций в качестве отличного IAuthorizationFilter - оба означают, что мы не гарантируем, что аутентификация происходит в первую очередь.

IAuthenticationFilter был первоначально добавлен в сборку MVC для решения этой проблемы, а затем перенесен для использования с WebAPI. Хорошую статью можно найти здесь; Фильтры безопасности ASP.NET Web API.

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

Аутентификация форм OWIN

Аутентификация форм OWIN - это запутанная фраза, которую я получил от чтения плохо сформулированной статьи (связанной выше). Он представляет собой две не зависящие от них компоненты решения:

Аспект "Формы" решения по-прежнему работает так же, как и для проверки подлинности форм ранее. Это следствие отказа авторизации (например, из атрибута [Authorize] или элемента web.config <authorization>) в сочетании с перенаправлением на форму входа в систему. (Ваш выбор технологии определит, где вы настраиваете URL-адрес для перенаправления. Для OWIN вы настроите его в CookieAuthenticationOptions.)

Аспект "OWIN" более важен для путаницы, вызвавшей мой OP. Я не буду подробно останавливаться на OWIN, поскольку это означает сделать гораздо больше, чем аутентификацию; полностью отделяя ASP.NET от IIS (через OWIN), он приводит к множеству плюсов и минусов, но MVC6 построен исключительно на OWIN, поэтому он здесь, чтобы остаться.

Для аутентификации текущие модули, такие как внешние поставщики аутентификации ASP.NET(социальный логин Facebook/Google), зависят от OWIN. Если вы пишете веб-аутентификацию ASP.NET "обычный" способ, вы будете использовать OWIN. Это преимущество аутентификации через OWIN.

Раньше социальный логин происходил в более мощном стиле как перенаправление, а MessageHandler назывался OAuthWebSecurity. OWIN предоставляет механизм как для перенаправления, так и для обработки обратного вызова поставщика аутентификации; прочитайте Создание пользовательского промежуточного ПО OAuth для MVC 5 для получения дополнительной информации.

ClaimsAuthenticationManager

ClaimsAuthenticationManager на самом деле это не похоже. Это действительно хвостовой аспект процесса аутентификации, который уже был выполнен Windows Identity Foundation (WIF). Он предназначен для преобразования требования, полученного в результате этого процесса, в соответствии с вашими потребностями. Например, список претензий может включать имя пользователя, из которого вы можете искать из часто используемых роли или прав базы данных, и добавлять их в список претензий по соображениям производительности.

Используется везде, где используется WIF. Относительно текущих веб-приложений ASP.NET это будет означать OWIN.

Резюме

Да. Вероятно, вы используете OWIN, WIF и файлы cookie в своем современном веб-приложении ASP.NET. Просто что-то принять, если вы используете "материалы в коробке", а также смерть WebForms и VB.NET в этом выпуске.

Итак, поскольку вы, вероятно, будете выполнять аутентификацию OWIN, вот отличная серия по этой теме; О чем этот материал Owin?

Ответ 2

OWIN - это больше возможностей для минимизации стека для обслуживания веб-страниц и минимизации стека - новая волна будущего (ala node.js). "промежуточное ПО аутентификации OWIN" - это то, о чем вы говорите, и Брок Аллен заявляет, что он лучше всего здесь:

http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/

С .NET 4.5.1 для приложений ASP.NET весь базовый код который обрабатывает "Индивидуальные учетные записи пользователей" (а также шаблоны в Visual Studio 2013) является новым. Это означает, что проверка подлинности на основе файлов cookie мы больше не используем аутентификацию форм и для внешней идентификации провайдеров мы больше не используем DotNetOpenAuth.

Замена - это платформа, называемая промежуточным программным обеспечением аутентификации OWIN и его ориентация на API OWIN. Я не собираюсь мотивировать OWIN здесь (это хорошая статья на эту тему), но вкратце ее абстракция API для веб-хоста. Многие фреймворки, такие как Web API и SignalR (как а также другие рамки, отличные от Microsoft) кодируются для этой абстракции поэтому они не требуют какого-либо конкретного веб-узла (такого как IIS).