Ответ 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?