Аутентификация с помощью форм
Аутентификация с помощью форм - это система аутентификации общего назначения, основанная на двух концепциях. Первая из них - страница входа (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, которые представляют успешно аутентифицированного пользователя приложения. Далее будет показано, как применять аутентификацию с помощью форм в разрабатываемых приложениях.
Давайте теперь перейдём к описанию процесса аутентификации непосредственно в рамках среды ASP.NET, где для вашего выбора предоставлены 3 вида аутентификации:
* Аутентификация 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 позволяет получить имя пользователя; определить тип аутентификации; установить, была ли аутентификация проведена анонимно; также можно узнать, прошёл пользователь аутентификацию или нет, гость он или системный пользователь.
Поскольку в приложениях ASP.NET для обращения к объекту WindowsIdentity нужно будет выстроить следующую цепочку:
HttpContext.Current.User.Identity, то вы сможете также определить, к какой роли принадлежит текущий пользователь. Это можно достичь благодаря тому, что свойство User в этой цепочке реализует интерфейс Iprincipal, который позволяет определить принадлежность пользователя к определённой роли путём вызова функции IsInRole, имеющей следующий синтаксис:
Public Overridable Function IsInRole(ByVal role As String) As Boolean Member of: System.Security.Principal.Iprincipal
Но давайте ненадолго отойдём от голой теории и попробуем реализовать практический пример. Для этого создайте новый проект ASP.NET Web Application и введите следующий код:
Default.aspx:
Authentication Sample
Default.aspx.vb:
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 Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim s As String s = “
Name: “ & HttpContext.Current.User.Identity.Name & “
” & _ “Authentication type: “ & HttpContext.Current.User.Identity.AuthenticationType.ToString & “
” & _ “Is authenticated: “ & HttpContext.Current.User.Identity.IsAuthenticated.ToString & “
” & _ “Is admin: “ & HttpContext.Current.User.IsInRole(“Administrator”).ToString & “
” Response.Write(s) End Sub End ClassЕсли был выбран режим аутентификации Windows и настройки IIS не вызвали никаких конфликтных ситуаций, то вы получите соответствующую информацию о своём текущем пользователе. Если же поле имени пользователя и типа аутентификации оказались пустыми, то вам нужно просто настроить IIS, для этого выполните следующие действия:
1. Откройте IIS и найдите виртуальный каталог с этим приложением
2. Откройте окно свойств для этого каталога и перейдите во вкладку Безопасность каталога. В рамке Анонимный доступ и проверка подлинности нажмите кнопку Изменить…
3. В появившемся окне (рис. 2) снимите флажок Анонимный доступ
На этом мы закончим рассмотрение аутентификации на основе Windows и перейдём к аутентификации формой.
Аутентификация формой:Аутентификация формой или, как её ещё называют аутентификация на основе Cookie-файлов, имеет ряд преимуществ над аутентификацией Windows.
* Во-первых, вы имеете возможность самому определить на свой вкус и цвет или на вкус и цвет пользователя внешний вид формы регистрации вместо однотипного окна регистрации Windows.
* Во-вторых, вы полностью контролируете вводимую информацию
* Сведения о пользователях теперь может храниться не только в SAM или Active Directory, но и в любом другом хранилище, в частности: база данных, каталог LDAP, XML-файлы или же обычный текстовый файл.
* Отпадает необходимость связывать политику безопасности сервера с политикой Web-приложения, поскольку, как уже было ранее сказано, все сведения о пользователях можно вынести в отдельное хранилище данных без каких-либо пересечений с учётными записями ОС.
Но, не смотря на такое изобилие возможностей аутентификации на основе формы, существует и одно весомое ограничение – пользователь должен разрешить применение cookie-файлов. Если его не будет, то аутентификация формой с применением средств ASP.NET работать не будет. Обратите внимание на слова “…с применением средств ASP.NET…”. Это означает, что не будет работать механизм, освобождающий разработчика от рутинных операций бесконечных проверок, иными словами, все запросы, поступившие от пользователя, ещё не прошедшего аутентификацию, переадресовываются на страницу регистрации, где он вводит необходимую информацию (чаще всего имя пользователя и пароль). Полученные сведения передаются среде ASP.NET, где происходит их верификация. В случае успеха пользователю передаётся cookie-файл, в котором содержится удостоверение об авторизации (Authorization ticket), имя пользователя и ключ для последующего получения идентификатора. В результате все последующие обращения броузера будут содержать в заголовках сведения об авторизации, направляемые на проверку в среду ASP.NET. Поэтому, если пользователь не поддерживает cookie, то все проверки о том, прошёл ли он аутентификацию, нужно будет осуществлять вручную, например, в предыдущих версиях ASP для этого применяли объект Session, примерно, в следующей форме:
If Not Session(“Registered”) = “1” Then Response.Redirect(“login.asp”) End If
Для использования аутентификации формой сперва нужно настроить конфигурацию Web-проекта. Для этого измените содержимое тэга файла Web.config следующим образом:
Давайте подробнее рассмотрим вышеприведённый код. Атрибут mode тэга определяет способ аутентификации. В предыдущих примерах мы использовали значение Windows, которое настраивало аутентификацию в режим аутентификации средствами Windows, теперь для работы на основе форм мы применяем режим Forms. Кроме этих двух констант существуют ещё 2: Passport и None – первая из них определяет аутентификацию на основе паспорта, о которой речь пойдёт позже, вторая отключает её вообще. Следующий тэг () присущ только аутентификации на основе формы и включает в себя следующие сведения:
* name – имя cookie-файла, в который будут внесены данные об успешном прохождении аутентификации
* loginUrl – определяет адрес страницы, на которую будет переадресован пользователь для прохождения регистрации
* protection – принимает значения All|None|Encryption|Validation и определяет способ защиты данных в cookie-файлах. Из допустимых значений видно, что можно ничего не делать с полученными данными и принимать их такими, какие они есть; можно сверять их; можно шифровать; а также есть возможность объединить верификацию с криптографией – такое значение используется по умолчанию.
* timeout – определяет промежуток времени в секундах, в течение которого cookie будет доступен
* path – этот атрибут задаёт полный путь к cookie-файлу. По умолчанию он содержит косую черту (/), которая раскрывает все пути. Менять этот параметр не рекомендуется, потому что некоторые броузеры чувствительны к регистру в пути, потому в результате изменений этого параметра вы можете отрезать некоторых пользователей от возможности проходить аутентификацию.
* requireSSL – этот атрибут принимает значения True или False (по умолчанию) и устанавливает необходимость применения протокола защищённых сокетов (SSL – Secured Sockets Layer)
* slidingExpiration – указывает, нужно ли пересоздавать cookie и удостоверение об авторизации, если истекает таймаут. Принимает значения true (по умолчанию) или false.
Выше были описаны все возможные атрибуты раздела forms,но для корректной работы приложения достаточно использовать лишь 3 из них, как это показано в следующем листинге:
Аутентификация формой с использованием отдельных XML-файлов:Давайте теперь создадим простую страницу регистрации пользователей, которая сверяет введённые имя и пароль с данными из XML-файла. Для этого сперва создайте XML-файл с именем users.xml следующего образца:
users.xml:
John one Mike two Bill three
База пользователей готова – теперь можно приступить к созданию пробного проекта регистрации пользователей. Весь необходимый код приведён ниже:
Default.aspx:
default
Default.aspx.vb:
Imports System.Web.Security Public Class _default 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 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 If context.Current.User.Identity.Name = “” Then Response.Redirect(“login.aspx”) Else Response.Write(“”) End If End Sub End Class
Registration
| Name | |
| Password | |
Authentication failed
Imports System.Xml Imports System.Web.Security Public Class WebForm1 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 btnLogin_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnLogin.Click Dim xd As New XmlDocument, xr As XmlNodeReader Dim sName As String, sPass As String " Открываем XML-файл xd.Load(Server.MapPath(“users.xml”)) ‘ Активируем XmlNodeReader xr = New XmlNodeReader(xd.Item(“users”)) " Ищем нужного пользователя While xr.Read If xr.Name = “name” And xr.NodeType = XmlNodeType.Element Then sName = xr.ReadString " Если не то имя пользователя, то переходим к другому If sName txtName.Text Then xr.Skip() ElseIf xr.Name = “password” And xr.NodeType = XmlNodeType.Element Then If xr.ReadString() = txtPassword.Text Then " Если пароли совпали, значит аутентификация проведена успешно FormsAuthentication.RedirectFromLoginPage(txtName.Text, True) Else " Если нет, то переходим к другому пользователю xr.Skip() End If End If End While " Если эта строка выполняется, значит данные о пользователе были введены неверно lbl.Visible = True End Sub End Class
Давайте теперь проведём “разбор полётов”: вышеприведённый код содержит в себе 2 страницы. Все действия начинаются на странице default.aspx, в которой происходит проверка, есть ли у текущего пользователя имя:
If context.Current.User.Identity.Name = “” Then Response.Redirect(“login.aspx”) Else Response.Write(“Hello “ & context.Current.User.Identity.Name & “”) End If
Если оно есть, то на экран будет выведено приветствие, в противном случае – пользователь будет переадресован на страницу регистрации login.aspx, где ему будет предложено ввести своё имя и пароль. Введённые сведения сверяются с данными из XML файла. Если пользователь не будет найден, появится сообщение об ошибке (рис. 3), в ином случае он будет благополучно переадресован на исходную страницу default.aspx, которая, обнаружив, что у текущего пользователя имя определено, поприветствует его.
Если вы успешно прошли аутентификацию и увидели приветствие, то закройте окно броузера и попробуйте заново запустить страницу default.aspx. Вы сразу увидите перед собой приветствие для того пользователя, чьё имя вы вводили в последний раз. Дело в том, что при регистрации мы сохранили на машине клиента cookie-файл. Это произошло в тот момент, когда мы в коде вызывали функцию RedirectFromLoginPage, передав её параметру CreatePersistentCookie значение True:
FormsAuthentication.RedirectFromLoginPage(txtName.Text, True)
Для того чтобы исключить передачу cookie файла достаточно вызвать эту функцию со значением False параметра CreatePersistentCookie. Или есть другой способ – в странице default.aspx добавьте обработчик события выгрузки страницы со следующим кодом:
Private Sub Page_Unload(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Unload FormsAuthentication.SignOut() End Sub
В результате, после выгрузки главной страницы пользователь будет регистрироваться о выходе.
Аутентификация формой с использованием файла конфигурации:В предыдущем примере мы хранили все данные о пользователях в отдельном XML-файле, но оказывается ASP.NET предоставляет возможность хранить сведения об аккаунтах прямо в файле конфигурации Web-проекта. Преимуществом этого метода является то, что для его реализации требуется значительно меньше программного кода, поскольку в данном случае программисту не нужно вручную просматривать XML-файл в поисках соответствующих совпадений – он лишь вызывает одну единственную функцию, которая и решает всё дело. Для того чтобы понять принцип работы этого механизма, давайте ещё раз обратимся к файлу конфигурации, а точнее к тэгу forms. Этот тэг помимо уже описанных ранее атрибутов может также включать раздел — сертификаты:
Web.config:
Как видно из вышеприведённого листинга, тэг credentials содержит один единственный атрибут – passwordFormat. Этот параметр определяет способ хранения пароля и принимает следующие значения:
* Clear – пароль сохраняется без каких-либо изменений
* SHA1 – пароль хэшируется методом SHA1 (Secure Hash Algorithm версии 1)
* MD5 – пароль хэшируется методом MD5 (Message Digest версии 5)
Если вы выберите какой-нибудь из алгоритмов хэширования, то пароль уже нельзя будет хранить в исходной форме в файле конфигурации – его нужно будет сперва хэшировать и лишь потом присвоить полученный результат атрибуту password. В противном случае, когда ASP.NET будет проводить аутентификацию, пароли просто не совпадут.
Теперь, когда мы имеем свежеиспечённую базу учётных записей, давайте вернёмся к предыдущему приложению и изменим код обработчика события нажатия кнопки регистрации в странице login.aspx:
login.aspx.vb:
Private Sub btnLogin_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnLogin.Click If FormsAuthentication.Authenticate(txtName.Text, txtPassword.Text) Then " Если пользователь найден в разделе сертификатов, значит, регистрация проведена ‘ успешно FormsAuthentication.RedirectFromLoginPage(txtName.Text, False) Else " Иначе – выводим сообщение об ошибке lbl.Visible = True End If End Sub
Теперь сравните этот код с тем, который использовался в предыдущем примере. Как видите, он сократился от множества условий и переборов до всего одного запроса, возвращающего True или False.
Мы специально сейчас не станем рассматривать пример кода, работающего с хэшированными паролями, чтобы не торопить события. Дело в том, что в 3-й части этой статьи, которая будет посвящена криптографии, вы узнаете обо всех тонкостях хэширования и шифрования данных и сможете сами применить эти методы на практике.
Аутентификация формой с использованием базы данных:Давайте теперь рассмотрим пример работы с ещё одним хранилищем данных о пользователях – с базой данных MS SQL Server. Большинство динамических сайтов используют базы данных для хранения содержимого сайта. Сведения о пользователях также не являются исключением и вполне могут занять своё место в общем пуле данных. Для того, чтобы своими глазами увидеть, как всё это происходит, давайте создадим тестовое приложение, которое вновь будет основано на уже известной нам странице регистрации, применяемой в предыдущих примерах. Прежде всего, необходимо приготовить базу данных, для этого откройте утилиту SQL Query Analyzer и выполните в ней следующий код, написанный на языке tSQL:
FormAuthUsers.sql:
Create database ‘FormAuthUsers’ and add table ‘Users’ CREATE DATABASE FormAuthUsers GO USE FormAuthUsers GO CREATE TABLE ( IDENTITY (1, 1) NOT NULL, (50), (50), CONSTRAINT PRIMARY KEY CLUSTERED () ON ) ON GO --Fill table ‘Users’ INSERT INTO Users (UserName, Password) VALUES(‘John’, ‘one’) GO INSERT INTO Users (UserName, Password) VALUES(‘Mike’, ‘two’) GO INSERT INTO Users (UserName, Password) VALUES(‘Bill’, ‘three’) GO --Create procedure ‘FindUser’ CREATE PROCEDURE FindUser @Name nvarchar(50), @Password nvarchar(50) AS SELECT COUNT(ID) FROM Users WHERE UserName = @Name AND Password = @Password GO
В результате выполнения этого кода на вашем SQL Server должна создаться база данных с именем “FormAuthUsers”, в которой вы сможете найти таблицу Users с тремя записями и хранимую процедуру FindUser. Эта процедура возвращает количество пользователей, удовлетворяющих запросу, который формируется из параметров, передаваемых этой процедуре.
Теперь, когда у нас готова база данных, мы можем приступить к созданию страницы, которая будет с ней работать. Для этого вновь возьмите за основу предыдущие примеры и замените обработчик события нажатия кнопки на странице login.aspx:
login.aspx.vb:
Imports System.Data.SqlClient Imports System.Web.Security Public Class WebForm1 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 btnLogin_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnLogin.Click Dim cn As New SqlConnection(“server=localhost;database=FormAuthUsers;uid=sa;pwd=;”) Dim cm As New SqlCommand(“FindUser”, cn) Dim n As Integer " Открываем соединение 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 " Если кого-то нашли, значит, регистрация пройдена успешно FormsAuthentication.RedirectFromLoginPage(txtName.Text, False) Else " если никого нет, значит, ошибка lbl.Visible = True End If cn.Close() End Sub End Class
Для корректной работы этой страницы убедитесь, что строка подключения подходит под вашу конфигурацию. Давайте разберёмся в том, что тут происходит. Во-первых, создаётся объект соединения SqlConnection, в качестве параметра которому передаётся строка подключения к базе данных:
Dim cn As New SqlConnection(“server=localhost;database=FormAuthUsers;uid=sa;pwd=;”)
После этого создаётся экземпляр объекта SqlCommand, который служит для выполнения команд работы с данными. Следующие строки кода открывают соединение, но при этом учитывается возможность исключений, которые вылавливаются обработчиком исключений try:
" Открываем соединение Try cn.Open() Catch ex As SqlException Response.Write(ex.Message) Exit Sub End Try
Если при открытии соединения возникают какие-либо сбои, то пользователь получает соответствующее сообщение, и операция прерывается.
После этого объект SqlCommand настраивается на выполнение хранимой процедуры, и подготавливаются параметры для её запуска. Для этих 7 строк кода, конечно же, существует альтернатива, состоящие из 1 строки кода:
cm.CommandText = "exec FindUser "" & txtName.Text & "", "" & txtPassword.Text & """
Но, не смотря на то, что этот код короче, время работы будет больше. Почему? Дело в том, что с этой строкой вы осуществляете оперативный запрос, т. е. Вы пишите непосредственно SQL-команду, которая вызывает хранимую процедуру. В результате вы передаёте по сети дополнительные данные в виде команды “exec”, которая в свою очередь занимает место в сетевом трафике; как только этот запрос достигнет сервера, то сначала выполнится команда “exec”, и лишь потом запустится нужная нам хранимая процедура FindUser. Кроме этого существует ещё более тяжёлый способ, который заключается в отказе от хранимых процедур и вставке всего необходимого кода запроса непосредственно в объект SqlCommand, в результате чего ещё больше дополнительной информации отправляется по сетевому трафику. Казалось бы, что это такой плюс-минус пара десятков байт, но, а если вам придётся работать с огромными запросами, код которых значительно больше, чем у нашей процедуры? Поэтому самым лучшим способом является использование хранимых процедур, поскольку в этом случае вы получаете чёткое разделение обязанностей, при котором клиентская страница отвечает только за ввод-вывод данных в доступной пользователю форме; SQL Server выполняет все операции с данными; а IIS выступает в роли посредника между клиентом и сервером – вот вам и трёхуровневая архитектура. Не загружайте “нежные” клиентские машины лишней работой – лучше доверьте её тяжёлой артиллерии, т. е. серверу.
Но вернёмся к нашему коду и продолжим его разбор: после определения типа команды и подготовки всех параметров мы благополучно выполняем эту команду, при чём, обратите внимание, что для выполнения используется функция ExecuteScalar. Её следует применять, когда в качестве результата вы получаете скалярную величину, т. е. число, что собственно и происходит в нашей процедуре FindUser – она возвращает количество записей, удовлетворяющих заданному условию:
В конце кода, получив количество найденных записей, мы просто анализируем это значение и выполняем соответствующие операции.
Аутентификация формой с использованием Web-служб:
Предположим, вы работаете в организации XYZ. Вам было поручено создать приложение, управляющее информацией о персонале вашей организации. Вы работаете над этим проектом уже 7 месяцев, и вдруг по соображениям безопасности вам было поручено разместить информацию о пользователях на совсем другом сервере, с которым активно работает другой отдел организации XYZ. Непосредственный доступ к серверу вам не обеспечили, поэтому ваш проект не может напрямую обращаться к базе данных с пользователями, расположенной на этом сервере. Для решения этой проблемы было решено дать вам возможность разработать Web-службу, через которую вы могли бы осуществлять контроль над аутентификацией пользователей.
Эта выдуманная история раскрывает ещё один способ, позволяющий проводить аутентификацию – использование Web-служб. Web-службы становятся особенно актуальными, когда у вас или у ваших клиентов нет полноценного доступа к серверу. Кроме того, Web-службы применимы не только к Web-приложениям, но они могут также быть использованы и программными продуктами, работающими на самых разнообразных платформах. Это стало возможно благодаря применению технологии SOAP (Simple Object Access Protocol), которая использует стандартные порты TCP/IP и протокол HTTP.
Для работы с Web-службой её, прежде всего, нужно создать. Для этого начните новый проект типа ASP.NET Web Service (рис. 4).
Теперь, используя код обработчика события нажатия кнопки регистрации из предыдущего примера, вставьте его в исходный код Web-службы, немного видоизменив до следующей формы:
AuthSrvc.asmx:
Imports System.Web.Services Imports System.Data.SqlClient _ Public Class Service1 Inherits System.Web.Services.WebService #Region " Web Services Designer Generated Code " Public Sub New() MyBase.New() "This call is required by the Web Services Designer. InitializeComponent() "Add your own initialization code after the InitializeComponent() call End Sub "Required by the Web Services Designer Private components As System.ComponentModel.IContainer "NOTE: The following procedure is required by the Web Services Designer "It can be modified using the Web Services Designer. "Do not modify it using the code editor. Private Sub InitializeComponent() components = New System.ComponentModel.Container() End Sub Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) "CODEGEN: This procedure is required by the Web Services Designer "Do not modify it using the code editor. If disposing Then If Not (components Is Nothing) Then components.Dispose() End If End If MyBase.Dispose(disposing) End Sub #End Region " Функция, осуществляющая проверку наличия пользователя с заданным именем и паролем Public Function Authenticate(ByVal UserName As String, ByVal Password As String, ByRef ErrMessage As String) As Boolean Dim cn As New SqlConnection("server=localhost;database=FormAuthUsers;uid=sa;pwd=;") Dim cm As New SqlCommand("FindUser", cn) Dim n As Integer " Открываем соединение Try cn.Open() Catch ex As SqlException " Если есть исключение, то передаём его описание параметру ErrMessage ErrMessage = ex.Message Exit Function End Try " Задаём тип команды cm.CommandType = CommandType.StoredProcedure " Добавляем параметры имени Dim prmName = New SqlParameter("@Name", SqlDbType.NVarChar, 50) prmName.Value = UserName cm.Parameters.Add(prmName) " Добавляем параметр пароля Dim prmPass = New SqlParameter("@Password", SqlDbType.NVarChar, 50) prmPass.Value = Password cm.Parameters.Add(prmPass) " Выполняем запрос n = cm.ExecuteScalar " Закрываем соединение cn.Close() " Анализируем полученный результат If n > 0 Then " Если кого-то нашли, значит, регистрация пройдена успешно Return True Else " если никого нет, значит, ошибка Return False End If End Function End Class
Вы можете проверить работоспособность службы, не отходя от кассы, для этого просто запустите её на выполнение в среде Visual Studio .NET. Если в службе не было ошибок, то увидите перед собой экран, на котором будут 2 гиперссылки. Одна из них ведёт к описанию Web-службы средствами языка WSDL (Web Service Description Language), а другая (Authenticate) позволяет протестировать службу. Нажмите на вторую гиперссылку и заполните таблицу параметров, в появившейся странице (рис. 5). Если вы введёте в поле UserName строку “John”, а в качестве пароля подставите “one”, то функция вернёт значение True:
http://localhost/AuthSrvc/AuthSrvc.asmx/Authenticate: true
Если изменить значение любого из этих полей на недействительное, т. е. на то, которого нет в базе данных, то результат соответственно будет противоположным – False.
Думаю, нет смысла детально разбирать код этой функции, потому что во многом она похожа на свою предшественницу из предыдущего примера. Но, тем не менее, следует обратить особое внимание на обработчик исключений. Если в листинге с базой данных он при возникновении каких-либо исключений просто выводил соответствующее сообщение на экран, то в Web-службе мы передаём сообщение об ошибке параметру ErrMessage функции Authenticate, который был объявлен по ссылке:.
" Открываем соединение Try cn.Open() Catch ex As SqlException " Если есть исключение, то передаём его описание параметру ErrMessage ErrMessage = ex.Message Exit Function End Try
В приложениях, которые будут использовать эту службу, мы встроим проверку на наличие каких-либо исключений, и при их обнаружении будем выводить соответствующее сообщение.
Теперь давайте создадим приложение, которое будет использовать эту Web-службу, но только на этот раз мы немного отойдём от темы и для разнообразия создадим приложение Windows:
1. Создайте новый проект типа Windows Application
2. Измените форму так, чтобы она была похожа на форму, изображённую на рис. 6, или можете просто подставить код в конструктор из следующего листинга.
3. В окне SolutionExplorer щёлкните правой кнопкой мыши по папке References и выберите в появившемся контекстном меню команду Add Web Reference…
4. Перед вами появится диалог установки ссылок к Web-сервисам. Введите в поле URL полный адрес к файлу.asmx и запустите поиск. В результате вы должны увидеть нечто подобное рисунку 7.
5. Нажмите на кнопку Add Reference, и в вашем проекте появится ссылка на указанную Web-службу.
6.
Теперь можно приступить к написанию программного кода, реализующего этот Web-сервис. Весь необходимый код приведён ниже:
AuthSrvcRelease.vb:
Public Class Form1 Inherits System.Windows.Forms.Form #Region " Windows Form Designer generated code " Public Sub New() MyBase.New() "This call is required by the Windows Form Designer. InitializeComponent() "Add any initialization after the InitializeComponent() call End Sub "Form overrides dispose to clean up the component list. Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) If disposing Then If Not (components Is Nothing) Then components.Dispose() End If End If MyBase.Dispose(disposing) End Sub "Required by the Windows Form Designer Private components As System.ComponentModel.IContainer "NOTE: The following procedure is required by the Windows Form Designer "It can be modified using the Windows Form Designer. "Do not modify it using the code editor. Friend WithEvents Label1 As System.Windows.Forms.Label Friend WithEvents Label2 As System.Windows.Forms.Label Friend WithEvents txtName As System.Windows.Forms.TextBox Friend WithEvents txtPassword As System.Windows.Forms.TextBox Friend WithEvents cmdExit As System.Windows.Forms.Button Friend WithEvents cmdLogin As System.Windows.Forms.Button Private Sub InitializeComponent() Me.Label1 = New System.Windows.Forms.Label Me.Label2 = New System.Windows.Forms.Label Me.txtName = New System.Windows.Forms.TextBox Me.txtPassword = New System.Windows.Forms.TextBox Me.cmdExit = New System.Windows.Forms.Button Me.cmdLogin = New System.Windows.Forms.Button Me.SuspendLayout() " "Label1 " Me.Label1.Location = New System.Drawing.Point(8, 8) Me.Label1.Name = "Label1" Me.Label1.Size = New System.Drawing.Size(40, 16) Me.Label1.TabIndex = 0 Me.Label1.Text = "Name:" " "Label2 " Me.Label2.Location = New System.Drawing.Point(8, 40) Me.Label2.Name = "Label2" Me.Label2.Size = New System.Drawing.Size(64, 16) Me.Label2.TabIndex = 1 Me.Label2.Text = "Password:" " "txtName " Me.txtName.Location = New System.Drawing.Point(80, 5) Me.txtName.Name = "txtName" Me.txtName.Size = New System.Drawing.Size(216, 20) Me.txtName.TabIndex = 2 Me.txtName.Text = "" " "txtPassword " Me.txtPassword.Location = New System.Drawing.Point(80, 37) Me.txtPassword.Name = "txtPassword" Me.txtPassword.PasswordChar = Microsoft.VisualBasic.ChrW(42) Me.txtPassword.Size = New System.Drawing.Size(216, 20) Me.txtPassword.TabIndex = 3 Me.txtPassword.Text = "" " "cmdExit " Me.cmdExit.DialogResult = System.Windows.Forms.DialogResult.Cancel Me.cmdExit.Location = New System.Drawing.Point(216, 72) Me.cmdExit.Name = "cmdExit" Me.cmdExit.Size = New System.Drawing.Size(80, 24) Me.cmdExit.TabIndex = 4 Me.cmdExit.Text = "Exit" " "cmdLogin " Me.cmdLogin.Location = New System.Drawing.Point(128, 72) Me.cmdLogin.Name = "cmdLogin" Me.cmdLogin.Size = New System.Drawing.Size(80, 24) Me.cmdLogin.TabIndex = 5 Me.cmdLogin.Text = "Login" " "Form1 " Me.AcceptButton = Me.cmdLogin Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13) Me.CancelButton = Me.cmdExit Me.ClientSize = New System.Drawing.Size(304, 103) Me.Controls.Add(Me.cmdLogin) Me.Controls.Add(Me.cmdExit) Me.Controls.Add(Me.txtPassword) Me.Controls.Add(Me.txtName) Me.Controls.Add(Me.Label2) Me.Controls.Add(Me.Label1) Me.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedDialog Me.MaximizeBox = False Me.MinimizeBox = False Me.Name = "Form1" Me.Text = "AuthSrvc Test application" Me.ResumeLayout(False) End Sub #End Region Private Sub cmdLogin_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdLogin.Click " Устанавливаем ссылку на объект Dim au As New localhost.Service1 Dim sErr As String, bln As Boolean " Осуществляем проверку Cursor = Cursors.WaitCursor bln = au.Authenticate(txtName.Text, txtPassword.Text, sErr) Cursor = Cursors.Default " - Но сперва учтём возможные исключения If sErr "" Then MsgBox(sErr) Exit Sub End If " - А теперь переходим к основной проверке If bln = True Then MsgBox("Hello " & txtName.Text, MsgBoxStyle.Information) Else MsgBox("Wrong data!", MsgBoxStyle.Exclamation) End If End Sub Private Sub cmdExit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdExit.Click End End Sub End Class
В этом примере можно увидеть очень простой код, который заключается в обычном вызове функции, которая выполняет все необходимые операции.
Как уже было ранее сказано, Web-службы основаны на технологии SOAP и потому могут быть использованы приложениями, работающими совсем на другой платформе. Мы не будем уходить далеко, отрекаясь от Windows, но попробуем вызвать эту же самую Web-службу без применения технологий.NET, т. е. непосредственно через SOAP. Для этого создайте следующий файл сценария на языке Visual Basic Script Edition (VBScript) и запустите его на выполнение:
SOAP.vbs:
" Создаём экземпляр объекта SoapClient Set sc = CreateObject("MSSOAP.SoapClient") " Соединяемся с веб-службой и вызываем метод Authenticate sc.mssoapinit "http://localhost/AuthSrvc/AuthSrvc.asmx?WSDL" If sc.Authenticate ("John", "one", s) = True Then MsgBox "Hello John", 64 Else MsgBox "Wrong data!!", 48 End If " Удаляем ссылку на объект Set sc = Nothing
Как видите, применяя объектную модель SOAP, вы можете обращаться к Web-службам, используя самые разнообразные языки программирования (даже скрипты!) и платформы.
Но не всё так идеально, как кажется. Под красивой обёрткой Web-сервисов скрываются подводные камни, в первую очередь – это их собственная безопасность. Web-службы имеют беззащитную XML-структуру, перехватив которую, можно легко понять и получить передаваемые данные. Чтобы исключить, а точнее уменьшить вероятность подобной утечки информации, необходимо обезопасить веб-службы. Для этих целей существует ряд технологий, но наиболее распространённые только три из них: правила Firewall’а, Secure Sockets Layer (SSL) и Virtual Private Network (VPN).
Если вы точно знаете, какие компьютеры будут обращаться к вашему Web-сервису, то в этом случае вам подойдёт вариант с применением правил Firewall’а, где вы можете задать ограничения и права для конкретных IP-адресов, поэтому данный метод больше применим для локальных сетей, где вам не приходится особо беспокоиться о конфиденциальности передаваемых сведений. Очень удобным средством для этого является Microsoft Security and Acceleration (ISA) Server. Он предлагает расширенные правила политики, позволяющие ограничить или, наоборот, открыть доступ к информации для конкретных клиентов.
SSL наибольшим образом подходит для сетей Internet. При его использовании данные шифруются и передаются между сервером и клиентом; поступившие данные после этого проходят аутентификацию, проверяя тем самым, от того ли источника пришли эти данные. Это происходит с применением сертификатов, которые должны находиться как у сервера, так и у клиента, поэтому с одной стороны использование сертификатов позволяет удостовериться, что данные попадают в нужные руки, но с другой стороны – нужно быть уверенным, что у получателя есть соответствующий сертификат. Таким образом, для применения SSL вам нужно:
1. Получить сертификаты: сертификаты бывают коммерческие и триальные. Разница между ними заключается в том, что коммерческий будет официально оформлен на покупателя и, соответственно, будет стоить денег, а триальный можно получить бесплатно, но при этом без официального оформления. Сертификат можно получить по следующему адресу: http://www.verisign.com/. Но какой бы тип сертификата вы не заказывали, загрузить вам всё равно нужно будет 2: один для сервера, а другой – для клиентов (его ещё называют Certificate Authority (CA)).
2. Настроить сервер и установить сертификаты на клиентских броузерах: далее для успешного прохождения аутентификации запросов SSL необходимо добавить сертификаты, как на сервере, так и на клиентских машинах. Более того, клиентские сертификаты предназначены не для компьютера, а для броузера, т. е., если пользователь использует и Internet Explorer, и Netscape, желательно выдать ему сертификаты для обоих обозревателей. Впрочем, и серверные сертификаты тоже предназначены для разных типов серверов (На Verisign вы сможете найти сертификаты для более чем 50 видов серверов), но всё отличие в том, что их, как правило, не меняют, разве только новую версию устанавливают.
ПРИМЕЧАНИЕ
Но, не смотря на отсутствие официальной регистрации, триальный сертификат является легальным.
VPN – это расширение локальной сети, основанное на применении глобальной, в частности, Internet’а. Например, пользователь, работающий на удалённой машине, может соединиться с локальной сетью по средствам VPN, используя при этом Internet. С помощью этой технологии вы можете отправлять данные между компьютерами через защищённое соединение, поскольку VPN обладает теми же средствами безопасности, что и локальная сеть. Одним из недостатков VPN необходимость в долговременном соединении для эффективной работы. Для обмена данными VPN работает со следующими протоколами: Microsoft Point-to-Point Tunneling Protocol (PPTP), поставляемый с Windows NT 4.0 и Windows 2000, или Layer Two Tunneling Protocol (L2TP), доступный в Windows 2000.
ПРИМЕЧАНИЕ
В списке соответствующих операционных систем приведены лишь те, начиная с версий которых, данные протоколы стали доступными, т. е. в число этих ОС должны войти и более поздние версии, например, Windows XP, Windows 2003 Server.
Web-службы и средства их безопасности – это очень интересные и актуальные темы, учитывая то, что рост популярности Web-сервисов пошёл резко вверх с появлением.NET Framework и VS.NET. Но мы не станем дальше углубляться в подробности, а вернёмся в русло этой статьи. Вы можете с лёгкостью сами освоить все эти технологии. Для этого вам нужно лишь немного желания, терпения и свободного времени. Я могу вам дать только путеводительные метки, которые смогут вас направить по нужному курсу:
* http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/default.asp
* http://www.microsoft.com/isaserver
* http://support.microsoft.com/default.aspx?scid=kb;EN-US;q307267
* http://www.w3.org/TR/wsdl.html
* http://www.w3.org/TR/SOAP/
Паспорт – это единая система регистрации, созданная Microsoft, им можно воспользоваться на любом Web-сайте, являющемся членом этой акции. Одним важным плюсом данной технологии является то, что пользователю не нужно помнить регистрационные данные для каждого сайта в отдельности, что часто случается, когда привычный для вас аккуант уже занят на определённом web-узле. Паспорт позволяет решить эту проблему благодаря тому, что он использует общую базу о пользователях, поэтому на сайтах, поддерживающих.NET паспорт вы будете вводить всегда одни и те же регистрационные данные: ваш e-mail и пароль.
Метод аутентификации на основе паспорта использует стандартные технологии Web для удобства использования и сохранения конфиденциальности:
* защищённый протокол SSL
* cookie-файлы
* JavaScript 1.2
* шифрование методом 3DES
Для того чтобы реализовать всю мощь возможностей паспорта, вам нужно выполнить следующие действия:
1. Загрузите.NET passport SDK по следующему адресу:http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrvpass.asp
2. После этого вам следует зарегистрировать свой сайт в службе.NET паспорта: http://go.microsoft.com/fwlink/?LinkID=9732. Если вы не выполните регистрацию, то ваши возможности будут крайне ограничены, и вы не сможете в полной мере получить ожидаемый результат, например, для выхода из системы (т. е. logout) вам придётся закрыть все окна броузера и после этого удалить все cookie-файлы с паспортными данными
Также как и при использовании других типов аутентификации, сначала нужно настроить файл конфигурации проекта. Следующий листинг демонстрирует базовое содержание раздела authentication файла настройки:
В этом коде мы задаём тип аутентификации паспортом, после чего задаём один единственный параметр, настраивающий аутентификацию паспортом – адрес страницы, на которую будет переадресован пользователь, при возникновении необходимости пройти регистрацию:
Ещё одна черта, объединяющая все виды аутентификации, — это интерфейс IIdendity, на основе которого были созданы все классы сведений о пользователе для различных видов аутентификации. Аутентификация паспортом тоже не является исключением из этого списка, и средством, реализующим все основные свойства, стал объект System.Web.Security.PassportIdentity инфраструктуры.NET Framework.
Для обозначения ссылки к регистрационной странице принято использовать специализированный логотип, подгружаемый через Интернет. Из-за того, что этот логотип обычно приходится использовать довольно часто, лучше всего создать отдельный элемент управления, реализующий компонент аутентификации. Для этого выполните следующие действия:
1. Cоздайте в VS.NET новый проект типа ASP.NET Web Application
2. Добавьте в него пользовательский элемент управления Web User Control и задаёте ему имя passport.ascx
3. Замените его исходный код на следующий:
passport.ascx.vb:
Imports System.Web.Security Public Class passport Inherits System.Web.UI.UserControl #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 Dim id As PassportIdentity " Получаем данные о текущем пользователе id = CType(context.User.Identity, PassportIdentity) " Отображаем кнопку регистрации Response.Write(id.LogoTag()) End Sub End Class 1. После этого измените имя страницы Web-проекта на login.aspx и введите следующий код структуры страницы: login.aspx: LogIn
Все основные действия по аутентификации пользователя берёт на себя объект PassportIdentity, а точнее служба Microsoft Passport, на которую.NET Framework выходит с помощью объекта PassportIdentity. Именно поэтому, вам остаётся только пожинать плоды, но для того, чтобы знать, что конкретно можно и нужно пожинать, обратитесь к таблице 1, в которой разъясняются все возможные атрибуты, описывающие зарегистрировавшегося пользователя.
| Имя атрибута | Описание |
| Accessibility | Определяет, следует ли допустить опции доступности для данного пользователя на всех узлах, являющимися членами Microsoft Passport |
| BDay_precision | Определяет точность атрибута Birthdate |
| Birthdate | Содержит дату или год рождения пользователя, в зависимости от значения атрибута BDay_precision |
| City | Идентификатор GeoID, хранящий информацию о местоположении пользователя |
| Country | Код страны пользователя по стандарту ISO 3166 |
| Directory | Пока не используется |
| Firstname | Имя пользователя |
| Flags | Содержит опции пользовательского профиля |
| Gender | Определяет пол пользователя |
| Lang_Preference | Идентификатор LCID национального языка пользователя |
| Lastname | Фамилия пользователя |
| MemberIDHigh | Уникальный идентификатор пользователя PUID высокого уровня |
| MemberIDLow | Уникальный идентификатор пользователя PUID низкого уровня |
| MemberName | Содержит имя пользователя и имя домена, разделённые знаком “@” |
| Nickname | Дружелюбное обращение к пользователю |
| Occupation | Содержит некоторую дополнительную информацию о пользователе, в частности, род деятельности |
| PostalCode | Почтовый индекс пользователя в США или в другой стране |
| PreferredEmail | Адрес электронной почты пользователя |
| ProfileVersion | Версия профиля пользователя |
| Region | Идентификатор GeoID, обозначающий место проживания пользователя в стране |
| TimeZone | Определяет часовой пояс, в котором проживает пользователь |
| Wallet | Определяет, хранит ли пользователь паспорт в бумажнике |
Табл. 1 – Опции профиля пользователя
Для получения доступа ко всем этим атрибутам есть два способа: методом GetProfileObject объекта PassportIdentity и через свойство Item того же объекта. Следующий листинг, написанный на языке C#, демонстрирует оба эти способа в действии:
default.aspx.cs:
using System.Web.Security;
…
private void Page_Load(object sender, System.EventArgs e)
{
PassportIdentity id;
id = (PassportIdentity)User.Identity;
Response.Write(id["Firstname"] + "
");
Response.Write(id.GetProfileObject("Lastname") + "
");
}
Теперь давайте вернёмся к нашему проекту с элементом управления passport.ascx и доведём страницу регистрации до ума. Для этого измените файлы login.aspx и login.aspx.vb следующим образом:
login.aspx:
LogIn
Please login...
Как известно, большинство сайтов имеют однотипную, общепринятую разметку страниц, неотъемлемой частью которой является верхний и нижний колонтитулы и, пожалуй,…
Элемент управления 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 :
Войти в систему
| Имя пользователя: | |
| Пароль: | 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:
Если у вас нет MSDN-библиотеки, то к её самому свежему изданию можно обратиться через интернет по адресу: http://msdn.microsoft.com/library/ .
В третьей, заключительной части данной статьи, мы рассмотрим очень актуальную и интересную тему - криптографию. Кроме теории и алгоритмов криптографии мы рассмотрим с различных сторон средства шифрования, предоставляемые платформой.NET Framework, и создадим простенький метод шифрования.
Цель урока : Изучить способ авторизации через Cookie, использование стандартных атрибутов доступа к контроллеру и методу контроллера. Использование IPrincipal. Создание собственного модуля (IHttpModule) и собственного фильтра IActionFilter.
Небольшое отступление: На самом деле в asp.net mvc все учебники рекомендуют пользоваться уже придуманной системой авторизации, которая называется AspNetMembershipProvider, она была описана в статье http://habrahabr.ru/post/142711/ (сейчас доступ уже закрыт), но обьяснено это с точки зрения «нажимай и не понимай, что там внутри». При первом знакомстве с asp.net mvc меня это смутило. Далее, в этой статье http://habrahabr.ru/post/143024/ - сказано, что пользоваться этим провайдером – нельзя. И я согласен с этим. Здесь же, мы достаточно глубоко изучаем всякие хитрые asp.net mvc стандартные приемы, так что это один из основных уроков.
Кукисы Кукисы – это часть информации, отсылаемая сервером браузеру, которую браузер возвращает обратно серверу вместе с каждым (почти каждым) запросом.Сервер в заголовок ответа пишет:
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
Например:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09-Jun-2021 10:18:14 GMT
Браузер (если не истекло время действия кукиса) при каждом запросе:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*
Устанавливаем cookie (/Areas/Default/Controllers/HomeController.cs):
public ActionResult Index()
{
var cookie = new HttpCookie()
{
Name ="test_cookie",
Value = DateTime.Now.ToString("dd.MM.yyyy"),
Expires = DateTime.Now.AddMinutes(10),
};
Response.SetCookie(cookie);
return View();
}
В Chrome проверяем установку:
Для получения кукисов:
var cookie = Request.Cookies["test_cookie"];
Делаем точку остановки и проверяем:
Примечание: подробнее можно изучить кукисы по следующей ссылке:
http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/
Приступим.
Создадим интерфейс IAuthentication и его реализацию CustomAuthentication (/Global/Auth/IAuthentication.cs):
Public interface IAuthentication { /// /// Конекст (тут мы получаем доступ к запросу и кукисам) /// HttpContext HttpContext { get; set; } User Login(string login, string password, bool isPersistent); User Login(string login); void LogOut(); IPrincipal CurrentUser { get; } }
Реализация (/Global/Auth/CustomAuthentication.cs):
public class CustomAuthentication: IAuthentication
{
private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();
private const string cookieName = "__AUTH_COOKIE";
public HttpContext HttpContext { get; set; }
public IRepository Repository { get; set; }
#region IAuthentication Members
public User Login(string userName, string Password, bool isPersistent)
{
User retUser = Repository.Login(userName, Password);
if (retUser != null)
{
CreateCookie(userName, isPersistent);
}
return retUser;
}
public User Login(string userName)
{
User retUser = Repository.Users.FirstOrDefault(p => string.Compare(p.Email, userName, true) == 0);
if (retUser != null)
{
CreateCookie(userName);
}
return retUser;
}
private void CreateCookie(string userName, bool isPersistent = false)
{
var ticket = new FormsAuthenticationTicket(1,
userName,
DateTime.Now,
DateTime.Now.Add(FormsAuthentication.Timeout),
isPersistent,
string.Empty,
FormsAuthentication.FormsCookiePath);
// Encrypt the ticket.
var encTicket = FormsAuthentication.Encrypt(ticket);
// Create the cookie.
var AuthCookie = new HttpCookie(cookieName)
{
Value = encTicket,
Expires = DateTime.Now.Add(FormsAuthentication.Timeout)
};
HttpContext.Response.Cookies.Set(AuthCookie);
}
public void LogOut()
{
var httpCookie = HttpContext.Response.Cookies;
if (httpCookie != null)
{
httpCookie.Value = string.Empty;
}
}
private IPrincipal _currentUser;
public IPrincipal CurrentUser
{
get
{
if (_currentUser == null)
{
try
{
HttpCookie authCookie = HttpContext.Request.Cookies.Get(cookieName);
if (authCookie != null && !string.IsNullOrEmpty(authCookie.Value))
{
var ticket = FormsAuthentication.Decrypt(authCookie.Value);
_currentUser = new UserProvider(ticket.Name, Repository);
}
else
{
_currentUser = new UserProvider(null, null);
}
}
catch (Exception ex)
{
logger.Error("Failed authentication: " + ex.Message);
_currentUser = new UserProvider(null, null);
}
}
return _currentUser;
}
}
#endregion
}
Суть сводится к следующему, мы, при инициализации запроса, получаем доступ к HttpContext.Request.Cookies и инициализируем UserProvider:
Var ticket = FormsAuthentication.Decrypt(authCookie.Value); _currentUser = new UserProvider(ticket.Name, Repository);
Для авторизации в IRepository добавлен новый метод IRepository.Login. Реализация в SqlRepository:
public User Login(string email, string password)
{
return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0 && p.Password == password);
}
UserProvider, собственно, реализует интерфейс IPrincipal (в котором есть проверка ролей и доступ к IIdentity).
Рассмотрим класс UserProvider (/Global/Auth/UserProvider.cs):
Public class UserProvider: IPrincipal { private UserIndentity userIdentity { get; set; } #region IPrincipal Members public IIdentity Identity { get { return userIdentity; } } public bool IsInRole(string role) { if (userIdentity.User == null) { return false; } return userIdentity.User.InRoles(role); } #endregion public UserProvider(string name, IRepository repository) { userIdentity = new UserIndentity(); userIdentity.Init(name, repository); } public override string ToString() { return userIdentity.Name; }
Наш UserProvider знает про то, что его IIdentity классом есть UserIdentity , а поэтому знает про класс User , внутри которого мы реализуем метод InRoles(role) :
Public bool InRoles(string roles) { if (string.IsNullOrWhiteSpace(roles)) { return false; } var rolesArray = roles.Split(new { "," }, StringSplitOptions.RemoveEmptyEntries); foreach (var role in rolesArray) { var hasRole = UserRoles.Any(p => string.Compare(p.Role.Code, role, true) == 0); if (hasRole) { return true; } } return false; }
В метод InRoles мы ожидаем, что придет запрос о ролях, которые допущены к ресурсу, разделенные запятой. Т.е., например, “admin,moderator,editor”, если хотя бы одна из ролей есть у нашего User – то возвращаем зачение «истина» (доступ есть). Сравниваем по полю Role.Code, а не Role.Name.
Рассмотрим класс UserIdentity (/Global/Auth/UserIdentity.cs):
public class UserIndentity: IIdentity
{
public User User { get; set; }
public string AuthenticationType
{
get
{
return typeof(User).ToString();
}
}
public bool IsAuthenticated
{
get
{
return User != null;
}
}
public string Name
{
get
{
if (User != null)
{
return User.Email;
}
//иначе аноним
return "anonym";
}
}
public void Init(string email, IRepository repository)
{
if (!string.IsNullOrEmpty(email))
{
User = repository.GetUser(email);
}
}
}
В IRepository добавляем новый метод GetUser(email) . Реализация для SqlRepository.GetUser() (LessonProject.Model:/SqlRepository/User.cs):
Public User GetUser(string email) { return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0); }
Почти все готово. Выведем CurrentUser в BaseController:
public IAuthentication Auth { get; set; }
public User CurrentUser
{
get
{
return ((UserIndentity)Auth.CurrentUser.Identity).User;
}
}
Да, это не очень правильно, так как здесь присутствует сильное связывание. Поэтому сделаем так, введем еще один интерфейс IUserProvider , из которого мы будем требовать вернуть нам авторизованного User:
public interface IUserProvider
{
User User { get; set; }
}
…
public class UserIndentity: IIdentity, IUserProvider
{
///
/// Текщий пользователь
///
public User User { get; set; }
…
public IAuthentication Auth { get; set; }
public User CurrentUser
{
get
{
return ((IUserProvider)Auth.CurrentUser.Identity).User;
}
}
А теперь попробуем инициализировать это всё.
Вначале добавим наш IAuthentication + CustomAuthentication в регистрацию к Ninject (/App_Start/NinjectWebCommon.cs):
Kernel.Bind().To().InRequestScope();
Потом создадим модуль, который будет на событие AuthenticateRequest совершать действие авторизации:
public class AuthHttpModule: IHttpModule
{
public void Init(HttpApplication context)
{
context.AuthenticateRequest += new EventHandler(this.Authenticate);
}
private void Authenticate(Object source, EventArgs e)
{
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;
var auth = DependencyResolver.Current.GetService();
auth.HttpContext = context;
context.User = auth.CurrentUser;
}
public void Dispose()
{
}
}
Вся соль в строках: auth.HttpContext = context и context.User = auth.CurrentUser . Как только наш модуль авторизации узнает о контексте и содержащихся в нем кукисах, ту же моментально получает доступ к имени, по нему он в репозитории получает данныепользователя и возвращает в BaseController. Но не сразу всё, а по требованию.
Подключаем модуль в Web.config:
…
План таков:
Поехали. Добавляем Html.Action(“UserLogin”, “Home”) – это partial view (т.е. кусок кода, который не имеет Layout) – т.е. выводится где прописан, а не в RenderBody().
_Layout.cshtml (/Areas/Default/Views/Shared/_Layout.cshtml):
@RenderBody() HomeController.cs: public ActionResult UserLogin() { return View(CurrentUser); }
UserLogin.cshtml (/Areas/Default/Views/Home/UserLogin.cshtml):
@model LessonProject.Model.User @if (Model != null) {
Контроллер входа выхода LoginController (/Areas/Default/Controllers/LoginController.cs):
Public class LoginController: DefaultController { public ActionResult Index() { return View(new LoginView()); } public ActionResult Index(LoginView loginView) { if (ModelState.IsValid) { var user = Auth.Login(loginView.Email, loginView.Password, loginView.IsPersistent); if (user != null) { return RedirectToAction("Index", "Home"); } ModelState["Password"].Errors.Add("Пароли не совпадают"); } return View(loginView); } public ActionResult Logout() { Auth.LogOut(); return RedirectToAction("Index", "Home"); } }
LoginView.cs (/Models/ViewModels/LoginView.cs):
public class LoginView
{
public string Email { get; set; }
public string Password { get; set; }
public bool IsPersistent { get; set; }
}
Страница для входа Index.cshtml (/Areas/Default/Views/Index.cshtml):
@model LessonProject.Models.ViewModels.LoginView @{ ViewBag.Title = "Вход"; Layout = "~/Areas/Default/Views/Shared/_Layout.cshtml"; } Вход @using (Html.BeginForm("Index", "Login", FormMethod.Post, new { @class = "form-horizontal" })) { Вход Email @Html.TextBox("Email", Model.Email, new { @class = "input-xlarge" })
Введите Email
@Html.ValidationMessage("Email") Пароль @Html.Password("Password", Model.Password, new { @class = "input-xlarge" }) @Html.ValidationMessage("Password") Войти }Запускаем и проверяем:
Все исходники находятся по адресу
