Настройка Membership API

ASP.NET --- Безопасность в ASP.NET --- Настройка Membership API

Прежде чем можно будет использовать интерфейс Membership API и элементы управления безопасностью ASP.NET, потребуется выполнить несколько шагов:

1. Сконфигурируйте аутентификацию с помощью форм в файле web.config обычным образом и запретите доступ анонимным пользователям.

2. Настройте хранилище данных членства. Например, если используется SQL Server, то в базе данных SQL Server придется создать несколько таблиц и хранимых процедур.

3. Сконфигурируйте в файле web.config строку подключения к базе данных и поставщика членства, который должен использоваться.

4. Создайте пользователей в хранилище данных членства с помощью веб-утилиты конфигурирования ASP.NET, либо воспользуйтесь собственной страницей администрирования, которая может быть реализована в веб-приложении с применением функций Membership API.

5. Создайте страницу входа, которая использует готовый элемент управления Login или класс Membership для проверки введенных удостоверений и аутентификации пользователей.

Все шаги по конфигурированию за исключением настройки поставщика можно выполнить с помощью ASP.NET WAT (Web Site Administration Tool - инструмент администрирования веб-сайтов), в состав которого входит мастер настройки безопасности. Выберите в меню Website (Веб-сайт) пункт ASP.NET Configuration (Конфигурация ASP.NET) в среде Visual Studio. Интерфейс WAT показан на рисунке ниже:

Если ASP.NET используется на машине с установленной версией SQL Server Express Edition, то не придется даже настраивать хранилище данных и конфигурировать поставщика членства. Просто запустите мастер настройки безопасности в WAT и начните с добавления пользователей в хранилище членства. Необходимое хранилище данных создается автоматически, как только будет создан первый пользователь. Причем оно будет создано автоматически, даже если к нему производится обращение программно, поскольку эта функциональность обеспечивается через SqlMembershipProvider.

Однако имейте в виду, что это работает только с SQL Server Express Edition! В случае применения какой-то другой версии SQL Server хранилище данных придется конфигурировать вручную, как будет описано в разделе "Создание хранилища данных" далее в статье.

Когда работа ведется с SQL Server Express Edition, класс SqlMembershipProvider автоматически создает новую базу данных по имени ASPNETDB.MDB в специальном каталоге App_Data веб-сайта. Эта база данных реализует полную схему, что необходимо для хранения и управления информацией о пользователях, ролях, назначения ролей пользователям и даже более того - для персонализации и профилей пользователей.

Если возникнет желание использовать в качестве хранилища информации о пользователях и ролях собственную базу данных, а не автоматически созданную, для этого понадобится сконфигурировать поставщика членства и информацию для его подключения, прежде чем запускать мастер настройки безопасности в WAT. Все шаги конфигурирования и работа Membership API "за кулисами" подробно рассматривается в последующих разделах.

Конфигурирование аутентификации с помощью форм

Интерфейс Membership API основан на аутентификации с помощью форм и предлагается в виде готовой к применению инфраструктуры для управления и аутентификации пользователей. Таким образом, в качестве первого шага приложение должно быть сконфигурировано на аутентификацию с помощью форм. Но на этот раз структура решения будет немного отличаться.

Часто к корневому каталогу приложения открывается доступ для анонимных пользователей, в то время как ограниченные ресурсы сохраняются в подкаталогах с ограниченным доступом. Эти подкаталоги имеют собственные файлы web.config, которые закрывают доступ анонимным пользователям. Как только кто-то пытается обратиться к ресурсам, расположенным в защищенном каталоге, исполняющая среда ASP.NET автоматически перенаправляет пользователя на страницу входа.

На рисунке ниже показана структура веб-приложения, которая отображена в проводнике решений (Solution Explorer) уже структурированного проекта Visual Studio:

Таким образом, в корневом каталоге веб-приложения нужно только сконфигурировать аутентификацию с помощью форм, включив следующий фрагмент:

<system.web>
      <authentication mode="Forms">
        <forms loginUrl="MyLogin.aspx" />
      </authentication>
</system.web>

Как видите, эта конфигурация указывает на применение аутентификации с помощью форм и открывает анонимный доступ к страницам. В защищенный подкаталог должен быть помещен дополнительный файл web.config со следующим содержимым:

<system.web>
      <authorization>
        <deny users="?"/>
      </authorization>
</system.web>

Эта конфигурация запрещает доступ любому анонимному пользователю к защищенной вложенной папке веб-сайта. Если какой-то не аутентифицированный пользователь попытается обратиться к ресурсам из этого каталога, то исполняющая среда ASP.NET автоматически перенаправит его на страницу входа (публично доступную). Естественно, понадобится создать страницу входа, но с помощью Membership API это намного легче и быстрее, в чем вы убедитесь, когда будете изучать элемент управления Login в следующей статье.

Создание хранилища данных

С помощью Membership API необходимо настроить хранилище данных, с которым будет работать ваш поставщик членства. Как уже упоминалось ранее, при использовании SQL Server Express Edition в сочетании с ASP.NET класс SqlMembershipProvider способен создать это хранилище автоматически.

Однако в случае применения любой другой версии SQL Server это хранилище должно создаваться вручную. Есть и ряд других причин для того, чтобы не использовать автоматически присоединяемую, основанную на файлах базу данных. Этими причинами являются производительность и параллелизм. Изложим некоторые основы.

В SQL Server Express Edition базы данных можно использовать двумя способами. Первый способ - классический, а это означает, что вы создаете или присоединяете базу данных к SQL Server Service, как привыкли это делать в предыдущих версиях. Система SQL Server затем получает полный контроль над базой данных и способна предоставить эту базу данных множеству приложений и множеству пользователей одновременно.

Второй режим - тот, в котором SQL Server Express Edition может применяться в режиме на основе файлов. Это значит, что приложение может обращаться к файлу базы данных SQL Server непосредственно, не подключая его к экземпляру SQL Server. Система SQL Server динамически подключает и отключает базу от локально выполняющейся версии SQL Server Express Edition всякий раз, когда требуется информация из этой базы данных. Поэтому файл базы данных блокируется только на короткий период времени (по сравнению с подключенными базами данных, которые блокируются сервером SQL Server на все время, пока работает служба SQL Server). Это облегчает копирование файла базы данных, поскольку он не блокирован (например, если нужно скопировать внесенные изменения на машину развертывания и т.п.).

Однако в то же время это требует некоторых накладных расходов при обращении к расположенной в файле базе данных, поскольку он должен быть подключен автоматически. Более того, на время, пока база данных подключена к выделенному приложению, ни одно другое приложение не может получить доступ к ней, поскольку база блокирована текущим активным приложением.

Режим базы на основе файлов подходит для клиентских приложений Windows, использующих SQL Server Express Edition на стороне клиента в качестве хранилища данных клиентской стороны, где в каждый момент времени один пользователь и одно приложение обращается к базе данных. Это удобно также для целей разработки, поскольку не понадобится управлять базами данных для всех проектов в SQL Server через Management Studio. Однако эта опция не очень подходит для рабочих сред, когда множество пользователей используют ваши (и, возможно, другие) веб-приложения, обращающиеся к содержимому базы данных.

Поэтому для рабочих сред рекомендуется ручное создание базы данных членства, как описано в настоящем разделе. В случае SqlMembershipProvider создание такого хранилища данных означает создание базы данных SQL Server и множества таблиц и хранимых процедур в ней. ASP.NET поставляется с множеством сценариев SQL, которые позволяют вручную создать необходимую базу данных и ее таблицы, необходимые для хранения информации о пользователях и ролях, используемой Membership API. Однако ASP.NET также поставляется с инструментом aspnet_regsql.exe, который создает таблицы автоматически. В случае специального поставщика потребуется подготовить и настроить источник данных, применяемый этим поставщиком, в соответствии с его документацией.

Инструмент aspnet_regsql.exe можно использовать двумя способами: либо через интерфейс мастера, либо из командной строки, указывая специальные переключатели командной строки. В любом случае понадобится запустить инструмент в окне командной строки Visual Studio, поскольку оно включает всю необходимую настройку путей к каталогу .NET Framework, содержащему нужные инструменты. Если вы просто запустите его без параметров, то увидите на экране интерфейс мастера, который проведет по всему процессу создания базы данных (утилита находится по адресу C:\Windows\Microsoft.NET\Framework\[Версия]):

На рисунке показано создание базы данных на SQL Server Express Edition. Поэтому для идентификации именованного экземпляра SQLEXPRESS к идентификатору (.\) машины вручную добавляется суффикс SQLEXPRESS. Это значит, что новая база данных будет создана на экземпляре SQL Sever по имени SQLEXPRESS. Кроме того, она создается как полноценная подключенная база данных (а не файловая версия, создаваемая автоматически). Именно так необходимо вручную создавать базу данных для полной версии SQL Server: либо просто опустить имя экземпляра (в этом случае SQLEXPRESS), либо указать собственное имя экземпляра. При установке SQL Server на целевую машину есть возможность выбрать имя экземпляра.

Мастер предоставляет выбор - создать необходимую базу данных или удалить таблицы из существующей. Если выбрать опцию <default> для базы данных, мастер ищет базу данных по имени aspnetdb на указанном сервере. Если таковая еще не существует, aspnet_regsql.exe создает ее, и в ней создаются необходимые таблицы. Если таблицы уже существуют в целевой базе данных, они остаются неизменными.

Как упоминалось ранее, инструмент aspnet_regsql.exe можно также использовать в командной строке. На самом деле, это хороший способ автоматизировать установку приложения - просто вызвать этот инструмент из командной строки и автоматически установить таблицы базы данных ASP.NET, требуемые для приложения. Например, чтобы установить таблицы базы данных Membership API, необходимо запустить следующую команду:

aspnet_regsql -S .\SQLEXPRESS -E -A all -d MyDatabase

Результат выполнения этой команды показан на рисунке ниже:

И снова обратите внимание, что вы работаете с локальным экземпляром SQL Server по имени SQLEXPRESS (которым является SQL Server Express Edition, установленный на вашей машине). Однако поскольку здесь создается полноценная, подключенная база данных, такой способ будет работать с любой версией SQL Server. В стандартной установке полноценной версии SQL Server (Standard или Enterprise) нужно опустить имя экземпляра (\SQLEXPRESS) или указать имя экземпляра, выбранное при установке SQL Server.

В таблице ниже перечислены наиболее важные переключатели командной строки инструмента aspnet_regsql.exe, необходимые для Membership API и связанных с ним служб приложений ASP.NET:

Инструмент aspnet_regsql.exe имеет также несколько дополнительных переключателей для установки состояний сеанса SQL Server, а также для конфигурирования зависимостей кэша SQL.

Сценарии базы данных для служб ASP.NET

Инструмент aspnet_regsql.exe выполняет несколько сценариев для создания (или удаления) базы данных членства и ее таблиц. Эти сценарии входят в состав .NET Framework; их можно найти в каталоге .NET Framework, как показано на рисунке ниже:

Существуют два типа сценариев - Install ... и соответствующие им Uninstall ... В то время как Install... устанавливают набор таблиц баз данных, таких как таблицы, необходимые для Membership API, сценарии Uninstall... удаляют те же таблицы и базы данных. В таблице ниже описаны сценарии установки, включенные в .NET Framework:

Если вы не хотите или не можете использовать aspnet_regsql.exe, эти сценарии можно выполнить через инструмент командной строки sqlcmd.exe. Например, для установки общих таблиц на сервере SQL Server Express Edition служит следующая команда:

sqlmnd -S .\SQLExpress -E -i InstallCommon.sql

Помните, что запускать эти сценарии не понадобится, если вы применяете aspnet_regsql.exe, поскольку данная утилита как раз и выполняет эти сценарии самостоятельно. Рекомендуется использовать aspnet_regsql.exe, когда это возможно, и обращаться к сценариям напрямую только в ситуациях, когда по какой-то причине применять aspnet_regsql.exe нельзя. (Причиной может быть политика в отношении информационных технологий, настройка сценариев SQL или же включение стандартных сценариев SQL в собственные сценарии SQL, которые применяются для развертывания приложения.) Однако вместо включения этих сценариев SQL в собственные сценарии развертывания рекомендуется добавить либо специальный код, либо командные файлы в пакет развертывания, а в них вызвать aspnet_regsql.exe.

С помощью переключателя -S указывается сервер и имя экземпляра целевого сервера SQL Server. Обычно имя экземпляра (заданное после \) не используется, но сервер SQL Server Express Edition устанавливается как именованный экземпляр, что позволяет впоследствии установить на той же самой машине другие версии и экземпляры SQL Server. Таким образом, для SQL Server Express Edition должно быть указано имя экземпляра, которым по умолчанию является SQLEXPRESS. В переключателе -E указывается, что доступ к SQL Server осуществляется через аутентификацию Windows, и, наконец, в переключателе -i задается входной SQL-сценарий, который должен быть выполнен.

На рисунке ниже показан результат выполнения предыдущей команды:

Не пугайтесь сообщений об ошибках. Поскольку эта команда выполняется администратором, выводятся сообщения об ошибках, т.к. невозможно выдавать, забирать или ограничивать привилегии системного администратора (sa, dbo, sys и т.д. - администратор владеет всеми правами).

Конфигурирование строки соединения и поставщика членства

При наличии установленного SQL Server Express Edition в конфигурации по умолчанию специально подготавливать хранилище данных и настраивать поставщик членства не понадобится, поскольку исполняющая среда ASP.NET использует поставщик SQL Server на основе файлов и создает необходимую базу данных автоматически.

Если же установленной копии SQL Server Express Edition нет, то хранилище должно быть создано вручную, как было описано в предыдущем разделе, а поставщик членства - сконфигурирован, как описано в настоящем разделе. Помните, что поставщик членства должен быть сконфигурирован в корневом файле web.config веб-приложения (имеется в виду файл web.config, размещенный в корневом каталоге веб-приложения). Это означает, что приведенная ниже конфигурация должна находиться в корневом web.config, а не в web.config внутри подкаталога веб-сайта, поскольку она затрагивает все веб-приложение.

Но если вы захотите использовать собственную базу данных SQL Server или даже собственного поставщика членства и хранилища, то придется соответствующим образом сконфигурировать этого поставщика, а также строку соединения с базой-хранилищем данных о членстве. Для этого нужно будет непосредственно модифицировать файл web.config или редактировать конфигурацию с помощью оснастки IIS консоли MMC, если приложение выполняется под управлением IIS.

В случае применения хранилища SQL Server (или другого хранилища на основе базы данных) первым делом должна быть настроена строка соединения. Это можно сделать в разделе <connectionStrings> файла web.config. Например, если используется локальная база данных по имени aspnetdb, в которой установлены таблицы с помощью инструмента aspnet_regsql.exe, как было показано ранее, то строка соединения должна выглядеть следующим образом (вспомните, что раздел <connectionStrings> находится непосредственно под элементом configuration>):

<configuration>
  <connectionStrings>
    <add name="MyMembershipConnString" 
    	connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnetdb;Integrated Security=True"/>
  </connectionStrings>
  
  <!-- ... -->
</configuration>

После настройки строки соединения с хранилищем данных о членстве понадобится сконфигурировать поставщик членства для приложения. Для этого необходимо добавить в файл web.config раздел <membership> (если его еще там нет) непосредственно внутри раздела <system.web>, как показано ниже (опять-таки, в корневом файле web.config, как описано в начале этого раздела - эмпирическое правило заключается в том, что эти конфигурации поставщика помещаются в корневой web.config, поскольку затрагивают все веб-приложение):

<configuration>
    <system.web>
      <membership defaultProvider="MyMembershipProvider">
        <providers>
          <add name="MyMembershipProvider"
               connectionStringName="MyMembershipConnString"
               type="System.Web.Security.SqlMembershipProvider"
               passwordFormat="Hashed"/>
        </providers>
      </membership>
    </system.web>
</configuration>

Внутри раздела <membership> можно добавить множество поставщиков как дочерние элементы раздела <providers>. В предыдущем коде показана допустимая конфигурация для поставщика SqlMembershipProvider. Важно не забыть об атрибуте defaultProvider. Этот атрибут указывает поставщика членства, который будет использоваться в коде.

Настроенные поставщики отображаются в веб-конфигурации ASP.NET при выборе переключателя Select a Different Provider for Each Feature (Выберите поставщика для каждой функции) в конфигурации поставщика. Это позволит выбирать отдельного поставщика для каждого средства, как показано на рисунке ниже:

В таблице ниже описаны наиболее важные свойства класса SqlMembershipProvider:

После настройки хранилища данных и поставщика членства полученную конфигурацию можно использовать в приложении или, например, для создания пользователей в WAT. И здесь следует иметь в виду одно важное обстоятельство - эффект от свойства applicationName конфигурации членства. Благодаря этому свойству, можно использовать одну базу данных поставщика членства для более чем одного приложения. Каждый пользователь, роль, профиль - в действительности любой объект в базе данных членства - подключается к записи о приложении. Если не указать свойство applicationName в конфигурации членства, то Membership API (и, таким образом, любой административный инструмент, подобный WAT) ассоциирует объекты с корневым приложением по имени "/".

Если свойство applicationName в конфигурации поставщика членства установлено, то любой объект, созданный Membership API, будет ассоциирован с приложением, имя которого указано в этом свойстве.

Проверка удостоверений через элемент управления Login работает только по отношению к объектам, которые ассоциированы с приложением, указанным в свойстве applicationName. Это значит, что если вы сконфигурируете поставщик членства с именем приложения TestApp и попытаетесь войти в систему, то Membership API (и потому все основанные на нем элементы управления) будет проверять имена и пароли только по отношению к пользователям, ассоциированными с записью о приложении TestApp - даже если пользователи с тем же именем и паролем есть в базе данных, но ассоциированы с другими приложениями. Это может привести к небольшим паузам при переходе от тестовой конфигурации к рабочей и изменении свойства applicationName, но на той же базе данных членства.

Создание аутентифицируемых пользователей

Для создания новых пользователей в ранее созданном хранилище членства запустите WAT, выбрав в меню Website (Веб-сайт) пункт ASP.NET Web Configuration (Веб-конфигурирование ASP.NET) в среде Visual Studio. Перейдите на вкладку Security (Безопасность) и щелкните на ссылке Create User (Создать пользователя), как показано на рисунке ниже:

Как только несколько пользователей созданы, к базе данных можно подключиться через проводник Server Explorer в Visual Studio (что потребует добавления в Server Explorer подключения к базе данных членства) или с помощью SQL Server Management Studio и просмотреть таблицы aspnet_Users и aspnet_Membership:

Как пароль, так и ответ на вопрос для восстановления пароля сохраняются базе данных в хешированном виде, поскольку в разделе конфигурации <membership> для поставщика была указана опция passwordFormat="Hashed", Это можно видеть при открытии таблицы aspnet_Membership, в которой хранятся эти значения:

После добавления пользователей к хранилищу информации о членстве их можно аутентифицировать с помощью Membership API. Для этой цели потребуется создать страницу входа, которая запрашивает у пользователя его имя и пароль, а затем проверяет эти данные по хранилищу удостоверений (в моем случае страница MyLogin.aspx, которую мы создали в статье «Реализация аутентификации с помощью форм»):

protected void LoginAction_Click(object sender, EventArgs e)
{
        Page.Validate();
        if (!Page.IsValid) return;
        
        if (Membership.ValidateUser(UsernameText.Text, PasswordText.Text))
        {
            FormsAuthentication.RedirectFromLoginPage(UsernameText.Text, false);
        }
        else
        {
            // Имя или пароль пользователя неправильны
            LegendStatus.Text = "Вы неправильно ввели имя пользователя или пароль!";
        }
}

Знать, какой именно поставщик в данный момент применяется приложением, не обязательно. Если необходимо использовать другого поставщика членства, для этого достаточно изменить конфигурацию, чтобы Membership API использовал другого поставщика. Приложению не известны какие-либо подробности применяемого поставщика. В следующей статье рассматриваются новые элементы управления безопасностью. Создавать вручную элементы управления для страниц входа больше не понадобится.

Если вы тестируете сайт на полной версии IIS то при запуске этого примера может возникнуть ошибка "Cannot open database "aspnetdb" requested by the login. The login failed. Login failed for user 'IIS APPPOOL\DefaultAppPool'". Это связано с тем, что применяемый в IIS пул приложений, используемый по умолчанию, не ассоциирован с SQL Server Express. т.е. чтобы это сделать нужно изменить удостоверение пользователя пула. Для этого в IIS Manager откройте раздел "Пулы приложений", выберите необходимый пул (в моем случае это DefaultAppPool), щелкните по нему правой кнопкой мыши и в контекстном меню выберите "Дополнительные параметры". В открывшемся диалоговом окне измените параметр Удостоверение на Loacal System:

После этого пул приложений будет использовать локального пользователя NT AUTHORITY, у которого есть доступ к SQL Server Express. Для этого пользователя нужно будет открыть расширенные права доступа, для этого откройте SQL Server Management Studio, откройте раздел Security --> Logins и для пользователя выберите в контекстном меню Properties. В разделе Server Roles установите допуск sysadmin:

Если вы тестируете сайт на встроенном в Visual Studio сервере IIS Express беспокоиться об этих деталях не нужно.