Самым базовым средством работы с ASP.NET Identity является аутентификация пользователей, и в этой статье я покажу как ее использовать. Ниже собраны базовые вопросы, которые могут возникнуть у вас в данный момент:
Аутентификация — это проверка учетных данных, предоставляемых пользователем. После успешной аутентификации пользователя, во все последующие запросы добавляется cookie-файл с идентификатором пользователя.
Зачем нужно использовать?
Система аутентификации проверяет подлинность пользователей и является первым шагом к ограничению доступа к важной части приложения.
Как использовать в рамках MVC?
В ASP.NET MVC используется атрибут авторизации, который применяется к контроллерам и методам действий для того, чтобы ограничить доступ неавторизованным пользователям.
Далее я продемонстрирую возможности систем аутентификации и авторизации Identity на учетных записях пользователей, хранящихся в локальной базе данных. Однако, в последующих статьях мы разберем аутентификацию через социальные сети (такие как Facebook, Вконтакте и т.д.)
Процесс аутентификации/авторизации
Платформа ASP.NET Identity полностью интегрирована в ASP.NET. Это означает, что вы можете использовать стандартные средства аутентификации/авторизации MVC вместе с Identity, такие как атрибут Authorize. В этой статье мы ограничим доступ к методу действия Index контроллера Home и реализуем функции, которые позволят идентифицировать пользователей, чтобы они могли получить к нему доступ. В примере ниже я применил атрибут Authorize:
Атрибут Authorize по умолчанию ограничивает доступ к методам действий для пользователей, не прошедших аутентификацию. Если вы запустите приложение и запросите представление Index контроллера Home (по любому из адресов /Home/Index, /Home или просто /), вы увидите сообщение об ошибке, показанное на рисунке ниже:
Платформа ASP.NET предоставляет полезную информацию о пользователе в объекте HttpContext, которую использует атрибут Authorize, чтобы проверить состояние текущего запроса и посмотреть, является ли пользователь аутентифицированным. Свойство HttpContext.User возвращает реализацию интерфейса IPrincipal, который определен в пространстве имен System.Security.Principal. Интерфейс IPrincipal определяет свойства и методы, перечисленные в таблице ниже:
Методы и свойства, определенные в интерфейсе IPrincipal
Название
Описание
Identity
Возвращает реализацию интерфейса IIdentity, описывающую пользователя, связанного с запросом.
Возвращает true, если пользователь является членом указанной роли.
Интерфейс IIdentity, реализация которого возвращается свойством Iprincipal.Identity, также содержит несколько полезных свойств:
Свойства интерфейса IIDentity
Название
Описание
AuthenticationType
Возвращает строку, описывающую механизм, который используется для аутентификации пользователей.
Возвращает true, если пользователь аутентифицирован.
Возвращает имя текущего пользователя.
ASP.NET Identity содержит модуль, который обрабатывает глобальное событие AuthenticateRequest жизненного цикла приложения в котором проверяет cookie в браузере пользователя, для определения того, является ли он аутентифицированным. Позже я покажу как используются эти cookie-файлы. Если пользователь аутентифицирован, ASP.NET задает свойству IIdentity.IsAuthenticated значение true. (В нашем приложении мы еще не реализовали функцию аутентификации, поэтому свойство IsAuthenticated будет всегда возвращать false.)
Модуль авторизации проверяет свойство IsAuthenticated и, если пользователь не прошел проверку, возвращает HTTP-статус 401 и завершает запрос. В этот момент модуль ASP.NET Identity перехватывает запрос и перенаправляет пользователя на страницу входа /Account/Login. Это URL-адрес, который я определил в классе IdentityConfig ранее:
Браузер перенаправит вас по адресу /Account/Login, но т. к. мы еще не добавили контроллер для этого запроса, появится ошибка 404.
Подготовка к реализации системы аутентификации
Даже несмотря на то, что наш запрос на данный момент заканчивается ошибкой, мы наглядно показали как вписывается Identity в жизненный цикл приложения ASP.NET. Следующий шаг — создать контроллер, обрабатывающий запрос к URL /Account/Login, для отображения формы входа в приложение. Добавьте сначала новый класс view-model в файл UserViewModels.cs:
Новый класс модели содержит свойства Name и Password, декларированные атрибутом Required, который говорит системы валидации модели, что эти свойства не должны иметь пустых значений. В реальном проекте не забывайте также добавлять клиентскую проверку при вводе пользователем имени и пароля. В данном проекте мы пропустим эту проверку, т. к. основная наша цель — разобраться в ASP.NET Identity.
Теперь добавьте контроллер Account в наше приложение, с кодом, показанным в примере ниже, который содержит две перегруженные версии метода Login. Обратите внимание, что здесь не реализована логика проверки достоверности модели, т. к. мы возвращаем представление для проверки учетных данных пользователя и входа пользователей в приложение.
Хотя этот код еще не относится к аутентификации пользователей, контроллер Account все же содержит некоторую полезную инфраструктуру, не относящуюся к ASP.NET Identity.
Во-первых, обратите внимание, что оба метода Login принимают строковый аргумент returnUrl. Когда пользователь запрашивает URL-адрес с ограниченным доступом, он перенаправляется по адресу /Account/Login со строкой запроса, содержащей адрес страницы с ограниченным доступом. Например, если сейчас вы запросите адрес /Home/Index, вас перенаправит на URL следующего вида:
С помощью параметра ReturnUrl мы сможем перенаправить пользователя, успешно прошедшего аутентификацию, на страницу, с которой он пришел. Это обеспечивает простой и понятный процесс навигации пользователя в приложении при аутентификации.
Далее обратите внимание на атрибуты, которые я применил к контроллеру и его методам действий. Функции контроллера Account (такие как смена пароля, например) по умолчанию должны быть доступны только авторизованным пользователям. Для этого мы применили атрибут Authorize к контроллеру Account и добавили атрибут AllowAnonymous к некоторым методам действий. Это позволяет ограничить методы действий для авторизованных пользователей по умолчанию, но открыть доступ неавторизованным пользователям для входа в приложение.
Наконец, мы добавили атрибут ValidateAntiForgeryToken который работает в связке с классом HtmlHelper, используемом в Razor в представлениях cshtml. Вспомогательный метод AntiForgeryToken защищает от , благодаря тому, что генерирует скрытое поле формы с токеном, который проверяется при отправке формы.
Последний подготовительный шаг — создание формы входа в приложение. Добавьте в папку /Views/Account файл представления Login.cshtml:
В этой разметке стоит обратить внимание на использование вспомогательного метода Html.AntiForgeryToken и создание скрытое поля с сохранением параметра returnUrl. В остальном — это обычная форма, генерируемая с помощью Razor.
Итак, мы завершили подготовку к созданию системы аутентификации. Запустите приложение и перейдите по адресу /Home/Index – система перенаправит вас на страницу входа:
Аутентификация пользователей
Запросы к страницам с ограниченным доступом успешно перехватываются и перенаправляются контроллеру Account, но учетные данные, предоставляемые пользователем, пока не проверяются системой аутентификации. В примере ниже вы можете увидеть, как мы завершим процесс входа пользователей в систему:
Самая простая часть — это проверка учетных данных, которую мы делаем с помощью метода FindAsync класса AppUserManager:
В дальнейшем мы будем многократно обращаться к экземпляру класса AppUserManager, поэтому мы создали отдельное свойство UserManager, который возвращает экземпляр класса AppUserManager с помощью метода расширения GetOwinContext() класса HttpContext.
Метод FindAsync принимает в качестве параметров имя и пароль, введенные пользователем, и возвращает экземпляр класса пользователя (AppUser в примере) если учетная запись с такими данными существует. Если нет учетной записи с таким именем или пароль не совпадает, метод FindAsync возвращает значение null. В этом случае мы добавляем ошибку в метаданные модели, которая будет отображена пользователю. ClaimsIdentity, который идентифицирует пользователя. Класс ClaimsIdentity является частью ASP.NET Identity и реализует интерфейс IIdentity, который был описан ранее. Экземпляры ClaimsIdentity создаются путем вызова статического метода CreateIdentityAsync() класса UserManager. Этому методу передается объект пользователя (IdentityUser) и тип аутентификации в перечислении DefaultAuthenticationTypes.
Следующий шаг — удаление всех старых аутентифицирующих файлов cookie и создание новых. Мы добавили свойство AuthManager в контроллере Account, которое возвращает объект, реализующий интерфейс IAuthenticationManager, который отвечает за выполнение аутентификации в ASP.NET Identity. В таблице ниже перечислено несколько полезных методов этого интерфейса:
Наиболее полезные методы интерфейса IAuthenticationManager
Название
Описание
SignIn(options, identity)
Вход пользователя в систему, что фактически означает создание аутентифицирующего cookie-файла
Выход пользователя из системы, который обычно означает удаление файлов cookie
Аргументами метода SignIn являются объект AuthenticationProperties, определяющий свойства настройки процесса аутентификации и объект ClaimsIdentity. Мы задали свойству IsPersistent объекта AuthenticationProperties значение true — это означает, что файлы cookie будут сохраняться между сессиями пользователей. Благодаря этому, если пользователь выйдет из приложения и зайдет, например, на следующий день, он будет автоматически аутентифицирован. (Есть и другие полезные свойства, определенные в классе AuthenticationProperties, но свойство IsPersistent является единственным, который широко используется на данный момент.)
После воссоздания файлов cookie мы перенаправляем пользователя по URL-адресу, который он просматривал до аутентификации (используя параметр returnUrl).
Давайте протестируем процесс аутентификации. Запустите приложение и перейдите по адресу /Home/Index. Браузер перенаправит вас на страницу входа, где необходимо ввести данные пользователя, которого мы создали ранее при тестировании панели администратора:
Двухфакторная аутентификация
В примере выше мы реализовали однофакторную систему аутентификации. Это означает, что для входа в систему пользователю нужно знать всего лишь пароль.
Давайте теперь перейдём к описанию процесса аутентификации непосредственно в рамках среды ASP.NET, где для вашего выбора предоставлены 3 вида аутентификации:
* Аутентификация Windows * Формой * Паспортом
Аутентификация Windows:
Как и следует из названия, этот метод основывается на использовании учётных записей Windows. Такой метод уместен, если вы создаёте приложение для локальной сети, и все действующие учётные записи и группы хранятся на заранее определённом домене. При этом нужно быть очень осторожными, назначая права доступа пользователям, поскольку вы одновременно задаёте и права для работы в Windows. Для того, чтобы настроить ASP.NET на работу в режиме Windows аутентификации необходимо изменить файл настройки Web-проекта Web.config или при необходимости конфигурационный файл всего сервера, расположенный по адресу WINDOWS_FOLDERMicrosoft.NET
Framework.NET versionCONFIGMachine.config. В нашем примере мы будем работать исключительно с файлом проекта – Web.config, в котором вам нужно найти раздел authentication и присвоить его атрибуту mode значение Windows:
Теперь можно приступить непосредственно к программированию и реализации аутентификации на основе Windows. В помощь вам класс WindowsIdentity, который служит специально для работы с аутентификацией Windows. Вообще, для аутентификации, базирующейся на Windows, существуют два основных класса, предоставляемых .NET Framework:
* GenericIdentity – только реализует интерфейс IIdentity и не относится к какому-то определённому типу аутентификации * WindowsIdentity – также является реализацией интерфейса IIdentity, но плюс ещё и включает методы, характерные только для аутентификации на основе Windows
Имя пользователя и группы хранятся в объекте WindowsIdentity в следующем формате: DOMAINUserName и DOMAINGroup соответственно. Исключение составляют лишь встроенные группы, например группа Administrators, для обращения к ней можно использовать строку подключения через WindowsIdentity: BUILTINAdministrators. Или же можно задать встроенную группу из перечисления System.Security.Principal.WindowsBuiltInRole.
Из рис. 1 видно, что объект WindowsIdentity позволяет получить имя пользователя; определить тип аутентификации; установить, была ли аутентификация проведена анонимно; также можно узнать, прошёл пользователь аутентификацию или нет, гость он или системный пользователь.
Рис. 1 – Объект WindowsIdentity
Поскольку в приложениях ASP.NET для обращения к объекту WindowsIdentity нужно будет выстроить следующую цепочку:
HttpContext.Current.User.Identity, то вы сможете также определить, к какой роли принадлежит текущий пользователь. Это можно достичь благодаря тому, что свойство User в этой цепочке реализует интерфейс Iprincipal, который позволяет определить принадлежность пользователя к определённой роли путём вызова функции IsInRole, имеющей следующий синтаксис:
Но давайте ненадолго отойдём от голой теории и попробуем реализовать практический пример. Для этого создайте новый проект ASP.NET Web Application и введите следующий код: Default.aspx:
Если был выбран режим аутентификации Windows и настройки IIS не вызвали никаких конфликтных ситуаций, то вы получите соответствующую информацию о своём текущем пользователе. Если же поле имени пользователя и типа аутентификации оказались пустыми, то вам нужно просто настроить IIS, для этого выполните следующие действия:
1. Откройте IIS и найдите виртуальный каталог с этим приложением 2. Откройте окно свойств для этого каталога и перейдите во вкладку Безопасность каталога. В рамке Анонимный доступ и проверка подлинности нажмите кнопку Изменить… 3. В появившемся окне (рис. 2) снимите флажок Анонимный доступ
Рис. 2 – Настройка IIS
На этом мы закончим рассмотрение аутентификации на основе Windows и перейдём к аутентификации формой.
Аутентификация формой:
Аутентификация формой или, как её ещё называют аутентификация на основе Cookie-файлов, имеет ряд преимуществ над аутентификацией Windows.
* Во-первых, вы имеете возможность самому определить на свой вкус и цвет или на вкус и цвет пользователя внешний вид формы регистрации вместо однотипного окна регистрации Windows. * Во-вторых, вы полностью контролируете вводимую информацию * Сведения о пользователях теперь может храниться не только в SAM или Active Directory, но и в любом другом хранилище, в частности: база данных, каталог LDAP, XML-файлы или же обычный текстовый файл. * Отпадает необходимость связывать политику безопасности сервера с политикой Web-приложения, поскольку, как уже было ранее сказано, все сведения о пользователях можно вынести в отдельное хранилище данных без каких-либо пересечений с учётными записями ОС.
