IAuthenticationFilter
Ранее в MVC IAuthorizationFilter было обычным местом для выполнения пользовательской аутентификации. Обоснование этого фильтра можно увидеть в сценарии, где приложение имеет две спецификации авторизации и только одну спецификацию аутентификации. Два варианта — добавление спецификации аутентификации в единую произвольную процедуру авторизации и создание всех трех этих спецификаций как отдельных IAuthorizationFilter — оба означают, что мы не гарантируем, что аутентификация произойдет первой.
IAuthenticationFilter изначально был добавлен в сборку MVC для решения этой проблемы, а затем перемещен для использования WebAPI. Хорошую статью по теме можно найти здесь; фильтры безопасности веб-API ASP.NET.
Строго говоря, 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, вот отличная серия статей на эту тему; О чем этот Оуин?
person
shannon
schedule
10.04.2015
Helios, который занимается этим. Я также жду следующих шагов, поскольку неясно, является ли OWIN правильным путем в будущем. - person Saravanan schedule 16.04.2014