Аутентификация с помощью форм
Аутентификация с помощью форм - это система аутентификации общего назначения, основанная на двух концепциях. Первая из них - страница входа (login page) , которая может удостоверить действительность пользователей (обычно сверяя комбинацию имени и пароля с базой данных или другим хранилищем данных). Вторая - это механизм предохранения и восстановления контекста безопасности при каждом запросе (обычно с применением cookie-набора). Таким образом, пользователю понадобится войти только один раз.
Как будет показано далее, ASP.NET включает всю необходимую инфраструктуру. Посредством аутентификации с помощью форм платформа ASP.NET создает cookie-набор безопасности для зарегистрированных пользователей, обслуживает их и автоматически поддерживает контекст безопасности для последующих запросов. Лучше всего то, что она управляет этим процессом эффективно и в высшей степени устойчиво противостоит подделкам.
Аутентификация с помощью форм основана на билетах (также называемых маркерами). Это значит, что когда пользователь регистрируется, он получает так называемый билет с базовой информацией о себе. Информация сохраняется в зашифрованном cookie-наборе, который присоединяется к ответу, так что автоматически отправляется в каждом последующем запросе.
Когда пользователь запрашивает страницу ASP.NET, которая не доступна анонимным пользователям, исполняющая среда ASP.NET проверяет, имеется ли билет аутентификации с помощью форм. Если нет, производится автоматическая переадресация на страницу входа. С этого момента начинаются ваши заботы. Вы должны создать эту страницу входа и внутри нее проверить пользовательское удостоверение. Если пользователь успешно прошел проверку, вы просто сообщаете инфраструктуре ASP.NET об успехе операции (вызвав метод класса FormsAuthentication), после чего исполняющая среда автоматически устанавливает cookie-набор аутентификации (который в действительности содержит билет) и переадресует пользователя на запрошенную им страницу. С этим запросом исполняющая среда определяет, что cookie-набор аутентификации с билетом имеется в наличии и открывает доступ к странице.
Этот процесс показан на рисунке ниже. Все, что понадобится сделать - это настроить аутентификацию с помощью форм в файле web.config, создать страницу входа и проверить внутри нее удостоверение пользователя.
Почему стоит использовать аутентификацию с помощью форм?Аутентификация с помощью форм - привлекательный выбор для разработчиков по нескольким причинам, которые перечислены ниже:
Вы получаете полный контроль над кодом аутентификации.
Вы получаете полный контроль над внешним видом формы входа.
Она работает с любым браузером.
Она позволяет выбирать способ хранения информации о пользователях.
Все эти причины более подробно рассматриваются в последующих разделах.
Контроль над кодом аутентификацииПоскольку аутентификация с помощью форм реализована полностью внутри ASP.NET, вы получаете полный контроль над выполнением аутентификации. Вам не нужно полагаться ни на какую внешнюю систему, как это имеет место при аутентификации Windows. Поведение аутентификации с помощью форм можно настроить под свои нужды.
Контроль над внешним видом формы входаВы имеете ту же степень контроля над внешним видом аутентификации с помощью форм, что и над ее функциональностью. Другими словами, входную страницу входа можно оформлять как вам угодно. Однако если вы не хотите заниматься этим, можете воспользоваться высокоуровневым API-интерфейсом членства (Membership API) и элементами управления безопасностью ASP.NET. В число этих элементов управления входит готовый к использованию и в высокой степени настраиваемый элемент управления Login.
Гибкость в настройке внешнего вида при других методах аутентификации недоступна. Аутентификация Windows требует, чтобы браузер запрашивал пользовательское удостоверение.
Работа с любым браузеромАутентификация с помощью форм использует в качестве пользовательского интерфейса стандартный HTML, так что все браузеры могут его обработать.
Для ввода и отправки пользовательского удостоверения аутентификация с помощью форм использует стандартные формы HTML. Это значит, что для шифрования и безопасной передачи этого удостоверения нужно применять SSL. В противном случае при обратной отправке данных на сервер информация передается как простой текст.
Хранение информации о пользователяхАутентификация с помощью форм по умолчанию хранит пользователей в файле web.config, но эту информацию можно хранить где угодно. Для этого понадобится только написать код, который обращается к хранилищу данных и извлекает информацию о пользователях. (В случае применения интерфейса Membership API даже этого делать не придется). Общим примером может служить хранение информации о пользователях в базе данных.
Гибкость в хранении информации о пользователях также означает возможность контроля над созданием и администрированием пользовательских учетных записей, а также присоединения дополнительной информации к этим учетным записям, такой как персональные предпочтения по настройке внешнего вида веб-сайта. Можно также присоединить специфические бизнес-детали, такие, например, как зашифрованная информация о кредитной карте, если сайтом является онлайновый магазин.
Когда не следует применять аутентификацию с помощью форм?До сих пор рассматривались причины, по которым аутентификация с помощью форм становится привлекательным выбором для регистрации пользователей. Однако аутентификация с помощью форм имеет и отрицательные стороны:
Вы должны самостоятельно создавать пользовательский интерфейс для регистрации пользователей. Можно либо целиком создать собственную страницу входа, либо использовать элементы управления безопасностью ASP.NET.
Вы должны поддерживать каталог удостоверений пользователей.
Вы должны предпринимать дополнительные предосторожности против вмешательства в сетевой трафик.
Более подробно об этом пойдет речь в последующих разделах. Первые два недостатка можно устранить за счет применения интерфейса Membership API, предоставляющего предварительно разработанные элементы управления и схему хранения удостоверений с готовым решением на основе SQL Server.
Создание собственного интерфейса регистрацииКак упоминалось ранее, аутентификация с помощью форм предоставляет полный контроль над интерфейсом, через который пользователи входят в ваше веб-приложение. Наряду с преимуществами, этот подход требует дополнительной работы, поскольку вы должны самостоятельно построить страницу входа. Другие варианты аутентификации предлагают готовые формы. Например, если применяется аутентификация Windows, браузер предложит стандартное диалоговое окно. В Passport-аутентификации для регистрации пользователей всегда применяется пользовательский интерфейс сайта Passport.
Создание страницы входа для аутентификации с помощью форм не требует много работы. Следует только отметить, что аутентификация с помощью форм - это только платформа для построения системы аутентификации, а не готовая к применению система.
С другой стороны, новый интерфейс Membership API включает предварительно подготовленный элемент управления Login, который может применяться либо на отдельной странице входа, либо в составе любой страницы веб-приложения. Пользовательский интерфейс является настраиваемым и при входе пользователя автоматически взаимодействует с Membership API. Элемент управления берет на себя большую часть работы по созданию настраиваемых страниц входа.
В большинстве случаев создание собственной страницы входа не требует ничего кроме добавления к решению страницы.aspx, содержащей этот элемент управления. Если поведение по умолчанию этого элемента управления устраивает (что бывает в большинстве случаев), то перехватывать какие-либо события или писать собственный код не придется.
Обслуживание информации о пользователяхПрименяя аутентификацию с помощью форм, вы возлагаете на себя ответственность за сопровождение подробной информации о пользователях, имеющих доступ к вашей системе. Наиболее важные детали - это удостоверения, которые пользователи должны предъявлять для входа в систему. Потребуется не только выбрать способ хранения их, но также обеспечить безопасность хранения. К тому же придется предоставить административные инструменты определенного рода для управления данными о пользователях в хранилище.
Платформа Membership API поставляется с предварительно созданной схемой для хранения удостоверений в базе данных SQL Server. За счет использования этой готовой схемы можно сэкономить массу времени. Более того, схема является расширяемой. Однако вы отвечаете за безопасное резервное копирование хранилища удостоверений - так, чтобы его можно было восстановить в случае сбоя системы.
Все сказанное не касается большинства других типов аутентификации. При Windows-аутентификации за хранение удостоверений пользователя отвечает лежащая в основе операционная система. В Windows реализовано множество приемов для автоматического обеспечения их безопасного хранения, так что выполнять дополнительную работу не придется. При аутентификации Passport удостоверения безопасно хранятся на специальных серверах Passport.
Перехват сетевого трафикаКогда пользователь вводит информацию удостоверения при аутентификации с помощью форм, она пересылается от браузера на сервер в формате простого текста. Это значит, что любой, кто ее перехватит, сможет ее прочитать. Очевидно, что такая ситуация небезопасна.
Обычное решение этой проблемы заключается в применении SSL (как было описано в предыдущей статье). На этом этапе может возникнуть желание использовать SSL для защиты только регистрационной страницы, а не всего приложения. Аутентификацию с помощью форм можно сконфигурировать так, чтобы она шифровала и подписывала cookie-наборы, в результате существенно затрудняя злоумышленнику задачу получения информации от нее. Вдобавок cookie-наборы не должны содержать никакой важной информации, и потому они не включают пароли, введенные при аутентификации.
Но что если злоумышленник перехватит незашифрованный трафик, извлечет из него cookie-набор (который уже зашифрован) и воспользуется им в своих целях? Расшифровывать его ему не понадобится - достаточно просто снабдить им собственные пересылаемые запросы. Противостоять такой атаке повтором можно только за счет применения SSL для всего сайта.
Другие механизмы аутентификации не требуют дополнительной работы. При Windows-аутентификации можно использовать протокол, который автоматически обеспечивает безопасный процесс регистрации (однако с одним предостережением - он поддерживается не всеми браузерами и не всеми сетевыми средами). При Passport-аутентификации процесс регистрации прозрачно обрабатывается Passport-серверами, которые всегда используют SSL.
Почему бы ни реализовать cookie-аутентификацию самостоятельно?В зависимости от конфигураций, о которых вы узнаете в последующих статьях, аутентификация с помощью форм использует cookie-наборы для выдачи билетов аутентификации клиентам и пользователям. Более общий термин для обозначения такого подхода называется cookie-аутентификацией. Аутентификация с применением cookie-наборов на первый взгляд кажется весьма простой системой. Может возникнуть вопрос: а почему бы ни реализовать ее самостоятельно, применяя cookie-наборы и переменные сеанса?
Причина - та же, по которой разработчики не реализуют другие средства ASP.NET, от состояния сеанса до платформы веб-элементов управления. Дело не только в том, что среда ASP.NET избавляет от забот, но также и в том, что она предлагает безопасную, хорошо протестированную и расширяемую реализацию. Ниже перечислены некоторые преимущества реализации аутентификации с помощью форм ASP.NET:
Cookie-наборы аутентификации являются защищенными.
Аутентификация с помощью форм - тщательно протестированная система.
Аутентификация с помощью форм интегрирована с классами безопасности.NET.
Аутентификация средствами cookie-наборов выглядит простой, но если ее реализовать неправильно, получится незащищенная система. Сами по себе cookie-наборы не являются безопасным местом хранения информации, поскольку злоумышленник может легко просмотреть и отредактировать данные cookie-набора. Если аутентификация основана на незащищенных cookie-наборах, хакер может легко подвергнуть опасности систему.
По умолчанию модуль аутентификации с помощью форм шифрует аутентифицирующую информацию перед помещением ее в cookie-набор. Он также снабжает ее хеш-кодом и проверяет cookie-набор при возврате на сервер, чтобы убедиться, что он не подвергался изменениям. Комбинация этих двух процессов обеспечивает безопасность cookie-наборов и избавляет от необходимости писать собственный код защиты. Большинство примеров доморощенных cookie-аутентификаций гораздо менее безопасны.
Аутентификация с помощью форм тщательно протестированаАутентификация с помощью форм - неотъемлемая часть ASP.NET, и как таковая используется во множестве веб-приложений и на множестве веб-сайтов. Когда столько людей применяют одну и ту же систему, все недостатки очень быстро выявляются, публикуются и разрешаются. До тех пор, пока вы вовремя устанавливаете все заплаты, можете считать себя в безопасности. С другой стороны, если вы создаете собственную систему аутентификации на основе cookie-наборов, то лишаетесь преимуществ такого массового тестирования. И первый случай обнаружения уязвимости будет связан с взломом вашей работающей системы.
Интеграция с платформой безопасности ASP.NETВсе типы аутентификации ASP.NET являются частью общей согласованной платформы. Аутентификация с помощью форм полностью интегрирована с этой платформой безопасности. Например, она наполняет объект контекста безопасности (IPrincipal), как и должна это делать. Это позволяет легко настроить поведение аутентификации с помощью форм по своему усмотрению.
Классы аутентификации с помощью формНаиболее важная часть платформы аутентификации с помощью форм - FormsAuthenticationModule. Это класс HttpModule, который обнаруживает билеты аутентификации с помощью форм, присутствующие в запросе. Если такой билет недоступен, а пользователь запросил защищенный ресурс, то запрос автоматически перенаправляется на страницу входа, указанную в файле web.config, еще до того, как исполняющая среда даже просто коснется этого защищенного ресурса.
Если билет присутствует, модуль автоматически создает контекст безопасности, инициализируя свойство HttpContext.Current.User экземпляром GenericPrincipal по умолчанию, который включает экземпляр FormsIdentity с именем текущего зарегистрированного пользователя. В основном напрямую работать с этим модулем не придется. Интерфейс для взаимодействия с модулем состоит из классов, перечисленных в таблице ниже, которые определены в пространстве имен System.Web.Security:
| FormsAuthentication | Основной класс для взаимодействия с инфраструктурой аутентификации с помощью форм. Он предоставляет базовую информацию о конфигурации и позволяет создавать билет, устанавливать cookie-наборы и перенаправлять со страницы входа на исходную запрошенную страницу в случае успешной проверки удостоверения пользователя |
| FormsAuthenticationEventArgs | FormsAuthenticationEventArgs инициирует событие Authenticate, которое можно перехватить. Соглашения о передаваемых аргументах события инкапсулируются в экземпляре этого класса. Содержит базовую информацию об аутентифицированном пользователе |
| FormsAuthenticationTicket | Этот класс предоставляет информацию о пользователе, которая будет зашифрована и помещена в cookie-набор аутентификации |
| FormsIdentity | Этот класс реализует интерфейс IIdentity и является специфичным для аутентификации с помощью форм. Ключевым дополнением класса FormsIdentity, кроме членов, необходимых для реализации интерфейса IIdentity, является свойство Ticket, представляющее билет аутентификации. Это позволяет сохранять и извлекать дополнительную информацию из билета, такую как кэшированная информация о роли для простых сценариев |
| FormsAuthenticationModule | Ядро инфраструктуры аутентификации с помощью форм, устанавливающее контекст безопасности и выполняющее при необходимости автоматическое перенаправление на страницу входа |
Большей частью придется использовать классы FormsAuthentication и FormsIdentity, которые представляют успешно аутентифицированного пользователя приложения. Далее будет показано, как применять аутентификацию с помощью форм в разрабатываемых приложениях.
Сергей Бакланов
| Imports System.Data.SqlClient Imports System.Web.Security Public Class login Inherits System.Web.UI.Page Protected WithEvents txtName As System.Web.UI.WebControls.TextBox Protected WithEvents txtPassword As System.Web.UI.WebControls.TextBox Protected WithEvents lbl As System.Web.UI.WebControls.Label Protected WithEvents btnLogin As System.Web.UI.WebControls.Button #Region " Web Form Designer Generated Code " "This call is required by the Web Form Designer. Private Sub InitializeComponent() End Sub "NOTE: The following placeholder declaration is required by the Web Form Designer. "Do not delete or move it. Private designerPlaceholderDeclaration As System.Object Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init "CODEGEN: This method call is required by the Web Form Designer "Do not modify it using the code editor. InitializeComponent() End Sub #End Region Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load "Put user code to initialize the page here End Sub Private Sub btnLogin_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnLogin.Click Dim cn As New SqlConnection("server=localhost;database=FormAuthUsers;uid=sa;pwd=;") Dim cm As New SqlCommand("FindUser", cn) Dim dr As SqlDataReader Dim ticket As FormsAuthenticationTicket Dim n As Integer, strRoles As String, strEncrypted As String " Открываем соединение Try cn.Open() Catch ex As SqlException Response.Write(ex.Message) Exit Sub End Try " Задаём тип команды cm.CommandType = CommandType.StoredProcedure " Добавляем параметры имени Dim prmName = New SqlParameter("@Name", SqlDbType.NVarChar, 50) prmName.Value = txtName.Text cm.Parameters.Add(prmName) " Добавляем параметр пароля Dim prmPass = New SqlParameter("@Password", SqlDbType.NVarChar, 50) prmPass.Value = txtPassword.Text cm.Parameters.Add(prmPass) " Выполняем запрос n = cm.ExecuteScalar If n > 0 Then " Если пользователь с таким именем и паролем существует, то ищем его роли cm = Nothing cm = New SqlCommand("exec FindRoles "" & txtName.Text & """, cn) dr = cm.ExecuteReader() " Составляем список ролей While dr.Read If strRoles = "" Then strRoles &= dr(0) Else strRoles &= ", " & dr(0) End If End While " Создаём аутентификационный билет ticket = New FormsAuthenticationTicket(1, txtName.Text, DateTime.Now, _ DateTime.Now.AddMinutes(20), False, strRoles) " Шифруем билет strEncrypted = FormsAuthentication.Encrypt(ticket) " Сохраняем cookie-файл Response.Cookies.Add(New HttpCookie("UrlAuthz", strEncrypted)) " Возвращаемся на исходную страницу FormsAuthentication.RedirectFromLoginPage(txtName.Text, False) Else " Если пользователь не был найден, то выдаём сообщение об ошибке lbl.Visible = True End If End Sub End Class |
В этом примере мы поместили в одну процедуру две операции проверки: одна - аутентификации, другая - авторизации. Сначала мы проходим аутентификацию, запрашивая данные на пользователя с таким-то именем и паролем из базы. Если пользователь не был найден, выводим соответствующее сообщение об ошибке (см. 4 строку снизу). Если же пользователь обнаружен, то мы определяем его роли, опять запрашивая информацию из базы данных. На основе полученных сведений о ролях формируется аутентификационный билет, который впоследствии шифруется и сохраняется в cookie-файле. И, наконец, пользователь благополучно возвращается на страницу default.aspx.
Поскольку в нашем файле конфигурации были прописаны ограничения доступа для нескольких файлов, то давайте разберём их содержимое (листинг 7).
Листинг 7. default.aspx
|
AuthzByUrl
Sub Page_Load(sender As Object, e As EventArgs) Handles MyBase.Load
If HttpContext.Current.User.Identity.Name = "" Then
lblLogin.Text = "You"re not registered, please login"
Else
lblLogin.Text = "You"re registered as " & _
HttpContext.Current.User.Identity.Name
End If
End Sub
Sub btnLogin_Click(sender As Object, e As EventArgs) Handles btnLogin.Click
Response.Redirect("login.aspx")
End Sub
You"re not registered, please login
GoTo:
|
admin.aspx
| admin |
После создания этого простого Web-узла вы сможете собственными глазами увидеть плоды своего труда. В приведённом коде указаны все инструкции, необходимые для создания действующей системы безопасности для сайта на базе аутентификации формой и авторизации с помощью URL.
Заимствование полномочийЗаимствование полномочий - это такой режим работы, при котором приложение ASP.NET функционирует от имени конкретного пользователя. Казалось бы, какой смыл вводить заимствование полномочий, если при аутентификации Windows пользователь и так заходит под конкретной учётной записью? Но всё дело в том, что идентификатор пользователя при аутентификации и идентификатор пользователя при заимствовании полномочий - это разные вещи, и применяются они соответственно для получения различной информации.
По умолчанию режим заимствования полномочий в среде ASP.NET отключён. Для его активизации нужно добавить в файл Web.config тэг и присвоить его атрибуту impersonate значение true. Следующий фрагмент файла конфигурации проекта демонстрирует, как это должно выглядеть:
Web.config
Для демонстрации работы этого режима, используйте следующий код (листинг 8) в странице default.aspx:
default.aspx
|
Impersonation
|
default.aspx.vb
| Imports System.Security.Principal Public Class WebForm1 Inherits System.Web.UI.Page #Region " Web Form Designer Generated Code " "This call is required by the Web Form Designer. Private Sub InitializeComponent() End Sub "NOTE: The following placeholder declaration is required by the Web Form Designer. "Do not delete or move it. Private designerPlaceholderDeclaration As System.Object Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init "CODEGEN: This method call is required by the Web Form Designer "Do not modify it using the code editor. InitializeComponent() End Sub #End Region Protected WithEvents clmIsAuthU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmAuthTypeU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmNameU As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmIsAuthW As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmAuthTypeW As System.Web.UI.HtmlControls.HtmlTableCell Protected WithEvents clmNameW As System.Web.UI.HtmlControls.HtmlTableCell Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim wi As WindowsIdentity " User.Identity With context.User.Identity clmIsAuthU.InnerText = .IsAuthenticated.ToString clmAuthTypeU.InnerText = .AuthenticationType.ToString clmNameU.InnerText = .Name End With " System.Security.Principal.WindowsIdentity wi = WindowsIdentity.GetCurrent With wi clmIsAuthW.InnerText = .IsAuthenticated.ToString clmAuthTypeW.InnerText = .AuthenticationType.ToString clmNameW.InnerText = .Name End With End Sub End Class |
В обработчике события загрузки формы для получения идентификатора пользователя объекта WindowsIdentity используется метод GetCurrent, возвращающий идентификатор учётной записи, от имени которой функционирует процесс ASP.NET.
При запуске этого приложения с отключенным заимствованием полномочий () перед вами появится экран, представленный на рисунке 3. Как можно наблюдать, при отключенном заимствовании полномочий в объекте WindowsIdentity содержится идентификатор системного пользователя ASPNET.
Теперь, если вы активизируете заимствование полномочий, то увидите результат, представленный в таблице 1.
Таблица 1. Включенное заимствование полномочий и отключенный анонимный доступ
| IsAuthenticated | True |
| Authentication type | Negotiate |
| Name | BIGDRAGON\B@k$ |
| IsAuthenticated | True |
| Authentication type | NTLM |
| Name | BIGDRAGON\B@k$ |
Как видите, результаты одинаковые, поскольку оба объекта получают информацию о текущем пользователе. Но предыдущие два примера были ориентированы на условия с запрещённым анонимным доступом для аутентификации средствами Windows. Если разрешить анонимный доступ к приложению, то объект User.Identity не вернёт никакого имени пользователя, а его свойство IsAuthenticated будет иметь значение False. В этом нет ничего удивительного, т. к. если в системе аутентификации Windows разрешён анонимный доступ, то пользователь работает анонимно, то есть не проходит аутентификацию.
В это же время у объекта WindowsIdentity свойство IsAuthenticated будет иметь значение True, а в качестве имени пользователя будет стоять строка следующего формата: IUSR_ , как показано в таблице 2.
Таблица 2. Заимствование полномочий и анонимный доступ разрешены
| IsAuthenticated | False |
| Authentication type | |
| Name | |
| IsAuthenticated | True |
| Authentication type | NTLM |
| Name | BIGDRAGON\IUSR_BIGDRAGON |
Свойство name объекта WindowsIdentity имеет такое значение потому, что оно возвращает идентификатор пользователя, под которым работает процесс ASP.NET, а не пользователь Web-узла. А поскольку процесс не может работать анонимно, то он получает имя от IIS, если его невозможно получить от текущего пользователя.
Если вы были внимательны при выполнении операций по разрешению/запрету анонимного доступа, то могли заметить, что в поле Имя пользователя была как раз подставлена строка вышеуказанного формата: IUSR_ (рис. 4).
Рисунок 4. В поле Имя пользователя содержится строка, определяющая имя процесса ASP.NET при анонимном доступе
Кроме того, в среде ASP.NET предусмотрена возможность указания, от кого именно заимствовать полномочия. С этой целью в тэге предусмотрен атрибут userName, в котором и указывается имя пользователя, у которого необходимо заимствовать полномочия.
В следующем фрагменте из файла Web.config, показано, как это должно выглядеть на практике:
Web.config
:
После запуска тестового приложения с такой конфигурацией на выполнение, состояние объекта User.Identity останется неизменным, а вот в свойстве name объекта WindowsIdentity вместо строки формата IUSR_ появится имя, указанное в атрибуте userName тэга из файла конфигурации проекта, как показано в таблице 3.
Таблица 3. Процесс ASP.NET работает от имени конкретного пользователя
| IsAuthenticated | False |
| Authentication type | |
| Name | |
| IsAuthenticated | True |
| Authentication type | NTLM |
| Name | BIGDRAGON\AlBa |
Если вы отмените анонимный доступ, то объект User.Identity будет содержать идентификатор зарегистрированного пользователя, а в объекте WindowsIdentity по-прежнему будет оставаться имя пользователя, переданное через атрибут userName.
На этом закончим изучение авторизации как средства безовасности среды ASP.NET. Дальнейшее изучение механизма авторизации требует изучения средств авторизации Windows. Среди них можно выделить списки контроля доступа на низком и высоком уровне, контроль доступа архитектуры клиент/сервер, ролевая безопасность Windows и так далее.
Если эта тема вас действительно заинтересовала, то вы можете найти массу материала в библиотеке MSDN:
- Темы безопасности в рамках ASP.NET доступны в следующей ветке библиотеки MSDN: .NET Development/.NET Security;
- По вопросам безопасности всей системы в целом следует обращаться к разделу Security/Security (General)/SDK Documentation.
Если у вас нет MSDN-библиотеки, то к её самому свежему изданию можно обратиться через интернет по адресу: http://msdn.microsoft.com/library/ .
В третьей, заключительной части данной статьи, мы рассмотрим очень актуальную и интересную тему - криптографию. Кроме теории и алгоритмов криптографии мы рассмотрим с различных сторон средства шифрования, предоставляемые платформой.NET Framework, и создадим простенький метод шифрования.
Последнее обновление: 31.10.2015
Релиз ASP.NET MVC 5 ознаменовался выходом новой системой авторизации и аутентификации в.NET приложениях под названием ASP.NET Identity. Эта система пришла на смену провайдерам Simple Membership, которые были введены в ASP.NET MVC 4.
Нажав на кнопку Change Authentication , мы можем изменить тип аутентификации, выбрав одно из следующих:
No Authentication : ASP.NET Identity и встроенная система аутентификации отсутствует
Individual User Accounts : проект по умолчанию включает систему ASP.NET Identity, которая позволяет авторизовать как пользователей внутри приложения, так и с помощью внешних сервисов, как google, твиттер и т.д.
Organizational Accounts : подходит для сайтов и веб-приложений отдельных компаний и организаций
Windows Authentication : система аутентификации для сетей intranet с помощью учетных записей Windows
Оставим значение по умолчанию, то есть Individual User Accounts и создадим проект.
Созданный проект уже по умолчанию имеет всю необходимую для авторизации инфраструктуру: модели, контроллеры, представления. Если мы заглянем в узел References (Библиотеки), то увидим там ряд ключевых библиотек, которые и содержит необходимые для авторизации и аутентификации классы:
Это ряд библиотек OWIN, которые добавляют функциональность OWIN в проект, а также три библиотеки собственно ASP.NET Identity:
Microsoft.AspNet.Identity.EntityFramework : содержит классы Entity Framework, применяющие ASP.NET Identity и осуществляющие связь с SQL Server oм
Microsoft.AspNet.Identity.Core : содержит ряд ключевых интерфейсов ASP.NET Identity. Реализация этих интерфейсов позволит выйти за рамки MS SQL Server и использовать в качестве хранилища учетных записей другие СУБД, в том числе системы NoSQL
Microsoft.AspNet.Identity.OWIN : привносит в приложение ASP.NET MVC аутентификацию OWIN с помощью ASP.NET Identity
Поскольку вся инфраструктура уже имеется в проекте, запустим проект, на отобразившейся в браузере странице найдем ссылку Register и нажмем на нее. На открывшейся странице регистрации введем какие-нибудь данные:
После регистрации логин будет отображаться в правом верхнем углу веб-страницы веб-приложения. Осуществив регистрацию, мы можем разлогиниться, нажав на LogOff, и снова войти в систему. Таким образом, мы можем уже начать пользоваться встроенной системой аутентификации в приложении ASP.NET MVC 5. Теперь же рассомотрим ее основные моменты.
Во-первых, где это все хранится? Куда попадают данные зарегистрированных пользователей?
В данном случае используется подход Code First. В файле web.config уже имеется строка подключения по умолчанию, которая задает каталог базы данных. Если мы раскроем папку App_Data, то сможем увидеть созданную базу данных:
Если вдруг в папке база данных не видна, нажмем вверху окна Solution Explorer на кнопку Show All Files (Показать все файлы).
Мы можем открыть эту базу данных в окне Server Explorer и увидеть ее содержимое:
По умолчанию при регистрации первого пользователя создается следующий набор таблиц:
MigrationHistory : используется EntityFramework для миграций БД
AspNetRoles : содержит определения ролей
AspNetUserClaims : таблица, хранящая набор клеймов (claim). Claim представляет иную модель авторизации по сравнению с ролями. Грубо говоря, claim содержит некоторую информацию о пользователе, например, адрес электронной почты, логин, возраст и т.д. И эта информация позволяет идентифицировать пользователя и наделить его соответствующими правами доступа.
AspNetUserLogins : таблица логинов пользователя
AspNetUserRoles : таблица, устанавливающая для пользователей определенные роли
AspNetUsers : собственно таблица пользователей. Если мы ее откроем, то увидим данные зарегистрированного пользователя
Ключевыми объектами в AspNet Identity являются пользователи и роли . Вся функциональность по созданию, удалению пользователей, взаимодействию с хранилищем пользователей хранится в классе UserManager . Для работы с ролями и их управлением в AspNet Identity определен класс RoleManager . Классы UserManager и RoleManager находятся в библиотеке Microsoft.AspNet.Identity.Core.
Каждый пользователь для UserManager представляет объект интерфейса IUser. А все операции по управлению пользователями производятся через хранилище, представленное объектом IUserStore.
Каждая роль представляет реализацию интерфейса IRole, а управление ролями классом RoleManager происходит через хранилище IRoleStore.
Непосредственную реализацию интерфейсов IUser, IRole, IUserStore и IRoleStore предоставляет пространство имен Microsoft.AspNet.Identity.EntityFramework:
Класс IdentityUser является реализацией интерфейса IUser. А класс хранилища пользователей - UserStore реализует интерфейс IUserStore.
Подобным образом класс IdentityRole реализует интерфейс IRole, а класс хранилища ролей - RoleStore реализует интерфейс IRoleStore.
А для взаимодействия с базой данных в пространстве имен Microsoft.AspNet.Identity.EntityFramework определен класс контекста IdentityDbContext
В приложении ASP.NET MVC мы не будем работать напрямую с классами IdentityUser и IdentityDbContext. По умолчанию в проект в папку Models добавляется файл IdentityModels.cs , который содержит определения классов пользователей и контекста данных:
Public class ApplicationUser: IdentityUser { public async Task GenerateUserIdentityAsync (UserManager manager) { var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); return userIdentity; } } public class ApplicationDbContext: IdentityDbContext { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } }
В приложении мы не работаем напрямую с классами IdentityUser и IdentityDbContext, а имеем дело с классами-наследниками.
Класс ApplicationUser наследует от IdentityUser все свойства. И кроме того добавляет метод GenerateUserIdentityAsync() , в котором с помощью вызова UserManager.CreateIdentityAsync создается объект ClaimsIdentity . Данный объект содержит информацию о данном пользователе.
Подобная архитектура позволяет взять уже готовый функционал и при необходимости добавить новый, например, добавить для пользователя новое свойство или добавить новую таблицу в бд.
Я не буду подробно расписывать весь функционал AspNet Identity, который по умолчанию добавляется в проект, обозначу вкратце лишь основные возможности.
Во-первых, чтобы задействовать AspNet Identity, в проект в папку App_Start добавляются два файла. Файл Startup.Auth.cs содержит класс запуска приложения OWIN. Поскольку AspNet Identity использует инфраструктуру OWIN, то данный класс является одним из ключевых и необходимых для работы.
Файл IdentityConfig.cs содержит ряд дополнительных вспомогательных классов: сервисы для двухфакторной валидации с помощью email и телефона EmailService и SmsService , класс менеджера пользователей ApplicationUserManager , добавляющий к UserManager ряд дополнительных функций, и класс ApplicationSignInManager , используемый для входа и выхода с сайта.
Базовая функциональность системы аутентификации и управления учетными записями расположена в двух контроллерах: AccountController и ManageController
В AccountController определены методы для логина, регистрации, верификации кода, отправленного по email или по смс, сброс пароля, напоминание пароля, вход на сайт с помощью внешних сервисов. Контроллер ManageController используется для управления учетной записью и предполагает возможности по смене пароля и управлению телефонными номерами в системе. Для обоих контроллеров уже по умолчанию генерируются все необходимые представления и специальные модели представлений.
Несмотря на то, что по умолчанию нам уже предоставляется готовый функционал, однако в ряде случаев, например, для отправки смс или электронной почты необходима дополнительная настройка. Теперь рассмотрим основные моменты системы AspNet Identity.
Элемент управления Login
Элемент управления Login упрощает создание страницы входа для аутентификации с помощью форм в сочетании с Membership API. Он предоставляет готовый к применению пользовательский интерфейс, запрашивающий имя и пароль пользователя и предлагающий кнопку для входа пользователя. "За кулисами" он инкапсулирует функциональность, которая была описана в предыдущей статье: проверку удостоверений пользователей через Membership API и инкапсуляцию базовой функциональности аутентификации с помощью форм, такой как перенаправление к изначально запрошенной странице в защищенной области приложения после успешного входа.
Это значит, что Login инкапсулирует такие вещи, как Membership.ValidateUser() или FormsAuthentication.RedirectFromLoginPage(), поэтому писать этот код самостоятельно не придется. На рисунке ниже показан элемент управления Login в действии:
Всякий раз, когда пользователь щелкает на кнопке Log In (Войти), элемент управления автоматически проверяет имя и пароль, применяя для этого функцию Membership.ValidateUser(), а затем вызывает FormsAuthenication.RedirectFromLoginPage(), если проверка прошла успешно. Все опции элемента управления Login влияют на ввод, доставляемый им в эти метода. Например, если отметить флажок Remember me next time (Запомнить учетные данные), он передаст значение true в параметре createPersistentCookie метода RedirectFromLoginPage(). Поэтому FormsAuthenticationModule создает постоянный cookie-набор.
"За кулисами" Login представляет собой составной элемент управления ASP.NET. Он полностью расширяем - в том смысле, что позволяет переопределять любые стили компоновки и свойства, а также перехватывать генерируемые события для переопределения его поведения по умолчанию. Если оставить элемент управления без изменений, как он есть, и не перехватывать никаких событий, то он автоматически будет использовать поставщик членства, сконфигурированный для приложения.
Простейшая форма элемента управления Login на странице выглядит следующим образом:
Для изменения внешнего вида элемента управления Login предназначено несколько свойств. Можно применять разные установки стилей, как показано ниже:
Кроме того, для настройки внешнего вида Login можно использовать классы CSS. Каждое свойство стиля, поддерживаемое элементом управления Login, включает свойство CssClass. Как и в случае любого другого элемента управления ASP.NET, это свойство позволяет указать имя класса CSS, который был добавлен ранее к веб-сайту. Предположим, что в проект добавлена следующая таблица стилей CSS с именем файла MyStyles.css:
MyLoginTextBoxStyle { cursor: pointer; background-color: yellow; text-align: center; padding:6px; border: dotted black; font-family: Verdana; vertical-align: middle; } .Login { display:inline-block; } .Title { padding: 6px; }
Этот файл стиля можно включить в страницу входа, чтобы иметь возможность использовать стиль для элемента Login:
В таблице ниже перечислены стили, поддерживаемые элементом управления Login. Каждый стиль работает одним и тем же способом. Свойства шрифта и цвета можно устанавливать непосредственно или применять свойство CssClass для указания нужного класса CSS:
| CheckBoxStyle | Определяет свойства стиля для флажка Remember me next time (Запомнить учетные данные) |
| FailureStyle | Определяет стиль для текста, который отображается а случае неудачного входа |
| HyperLinkStyle | Элемент управления Login позволяет определить несколько типов гиперссылок, например, на страницу начальной регистрации. Этот стиль задает внешний вид таких гиперссылок |
| InstructionTextStyle | Элемент управления Login позволяет указать текст справки, отображаемый непосредственно в нем самом. Этот стиль задает внешний вид этого текста |
| LabelStyle | Определяет стиль для меток User Name (Имя пользователя) и Password (Пароль) |
| LoginButtonStyle | Определяет стиль кнопки входа |
| TextBoxStyle | Определяет стиль для текстовых полей User Name (Имя пользователя) и Password (Пароль) |
| TitleTextStyle | Определяет стиль текста заголовка для элемента управления Login |
| ValidatorTextStyle | Определяет стили для элементов управления, используемых для проверки имени и пароля пользователя |
Пользовательский интерфейс элемента Login настраивается не только через эти стили; другие дополнительные свойства предназначены для определенных частей содержимого элемента управления, таких как кнопка Log In, которые также позволяют настроить графический интерфейс.
Например, можно выбрать текст, отображаемый на кнопке входа, либо вообще отображать вместо этой кнопки (как установлено по умолчанию) гиперссылку. Более того, к элементу управления Login можно добавить несколько гиперссылок, таких как ссылка на страницу справки или на страницу регистрации. Обе страницы должны быть открыты для анонимного доступа, поскольку справка должна предлагаться также анонимным пользователям (вспомните, что если кто-то видит элемент управления Login, то он - потенциально анонимный пользователь). Чтобы включить дополнительные ссылки в Login, модифицируйте ранее показанное определение следующим образом:
...
Этот код приводит к отображению двух дополнительных ссылок - на страницу справки и на страницу первоначальной регистрации, а также добавляет текст краткой инструкции под заголовком элемента Login:
Стили, описанные ранее, применимы и к этим свойствам. В таблице ниже описаны важные свойства для настройки элемента управления Login:
| Текст сообщений | |
| TitleText | Текст, отображаемый в заголовке элемента управления |
| InstructionText | Это свойство уже использовалось в предыдущем фрагменте кода. Содержит текст, отображаемый ниже заголовка элемента управления |
| FailureText | Текст, отображаемый элементом управления Login, если попытка входа не удалась |
| UserNameLabelText | Текст, отображаемый в виде метки перед текстовым полем имени пользователя |
| PasswordLabelText | Текст, отображаемый в виде метки перед текстовым полем пароля пользователя |
| UserName | Начальное значение, заполняющее текстовое поле имени пользователя |
| UsernameRequiredErrorMessage | Сообщение об ошибке, отображаемое, если пользователь не ввел имя |
| PasswordRequiredErrorMessage | Сообщение об ошибке, отображаемое, если пользователь не ввел пароль |
| Кнопка входа | |
| LoginButtonText | Текст, отображаемый на кнопке входа |
| LoginButtonType | |
| LoginButtonImageUrl | Если кнопка входа представлена как графическое изображение, необходимо указать URL, где находится это изображение |
| Страница входа | |
| DestinationPageUrl | Если попытка входа была успешной, элемент управления Login перенаправляет пользователя на эту страницу. По умолчанию это свойство пусто. При пустом значении используется инфраструктура аутентификации с помощью форм для перенаправления либо на исходную запрошенную страницу, либо на defaultUrl, сконфигурированный в web.config для аутентификации с помощью форм |
| FailureAction | Определяет действие, которое элемент управления выполняет после неудачной попытки входа. Два допустимых варианта - Refresh и RedirectToLoginPage. Первое значение приводит к обновлению только текущей страницы, а второе - к перенаправлению на сконфигурированную страницу входа. Второй вариант полезен, если элемент управления Login используется где-то в другом месте, а не на странице входа |
| VisibleWhenLoggedIn | Если установлено в false, то элемент управления автоматически скрывает себя, если пользователь уже вошел. Если установлено в true (по умолчанию), то элемент Login отображается, даже если пользователь совершил вход |
| Настройка метки "Запомнить меня" | |
| DisplayRememberMe | Позволяет показывать или скрывать флажок Remember me next time (Запомнить меня). По умолчанию это свойство установлено в true |
| RememberMeSet | Определяет значение по умолчанию флажка Remember me next time. По умолчанию это свойство установлено в false, т.е. флажок не отмечен |
| Страница регистрации | |
| CreateUserUrl | Определяет гиперссылку на страницу веб-сайта, которая позволяет создавать (регистрировать) пользователя. Таким образом, это обычно используется для открытия пользователю доступа к странице первичной регистрации. Обычно при этом отображается элемент управления CreateUserWizard |
| CreateUserText | |
| CreateUserIconUrl | URL-адрес графического изображения, выводимого вместе с текстом гиперссылки CreateUserUrl |
| Страница помощи | |
| HelpPageUrl | URL-адрес для перенаправления пользователя на страницу справки |
| HelpPageText | |
| HelpPageIconUrl | URL-адрес значка, отображаемого вместе с текстом гиперссылки HelpPageUrl |
| Страница восстановления пароля | |
| PasswordRecoveryUrl | URL-адрес для перенаправления пользователя на страницу восстановления пароля. Эта страница применяется, когда пользователь забыл пароль. Обычно она отображает элемент управления PasswordRecovery |
| PasswordRecoveryText | |
| PasswordRecoveryIconUrl | URL-адрес значка, отображаемого вместе с текстом гиперссылки PasswordRecoveryUrl |
Как видите, благодаря всем этим свойствам элемент управления Login настраивается очень гибко. Но как вы, скорее всего, обратили внимание, определить какое-нибудь выражение для проверки достоверности ввода невозможно. Конечно, можно реализовать проверку достоверности на стороне сервера внутри процедур событий, предлагаемых элементом управления Login. Когда требуется добавить какие-то элементы к составному элементу управления Login, это не получится сделать через представленные выше свойства. Например, что если понадобится второе текстовое поле для надежной аутентификации со вторым паролем или пользовательским ключом доступа, как это делается на некоторых правительственных сайтах?
К счастью, подобно другим элементам управления, таким как GridView, элемент Login поддерживает шаблоны. С помощью шаблонов можно настраивать содержимое элемента управления Login без каких-либо ограничений. К нему можно добавлять любые новые элементы управления. Применяется специальный шаблон к элементу управления Login с помощью дескриптора LayoutTemplate :
Войти в систему
| Имя пользователя: | |
| Пароль: |
Больше информации по теме
|
