Система безопасности DotNetNuke

Теоретическое введение

Безопасность в ASP.NET 2.0

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

В ASP.NET 2.0 были внедрены ряд улучшений в этой процедуре:

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

Модель провайдеров в DNN

Модель провайдеров - это архитектурный шаблон, который был использован при разработке DNN. Она позволяет заменять функциональность отдельных компонентов ядра без модификации кода ядра. Целью модели провайдеров является предоставление документированного и легкого для понимания API, который отличается простотой и расширяемостью.

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

Использование модели провайдеров дает программисту независимость API от деталей реализации API. Тем самым, реализация API может быть легко изменена.

Модель провайдеров используется в DNN для следующих целей:

Одной из реализации модели провайдеров в DNN является провайдер данных. Изначально (в ранних версиях) DNN поддерживал только СУБД MS SQL Server. Ядро портала было тесно связано с уровнем данных. Однако существовала объективная необходимость в поддержке других способов хранения данных. Решение было найдено во введении так называемого уровня доступа к данным (Data Access Layer), позволяющего организовать поддержку различных способов хранения данных.

API провайдера данных не зависит от реализации API (рис. 13.1). API провайдера данных не имеет никаких сведений о том, какой тип источника данных будет использоваться, до тех пор, пока он не будет сконфигурирован в файле web.config. Может использоваться любой источник данных, обеспечивающий необходимую функциональность.

Использование модели провайдеров имеет большое значение для DNN, поскольку позволяет заменять реализацию функциональности без модификации кода ядра. В DNN, как и в большинстве приложений с открытым кодом, код ядра не должен модифицироваться конечными пользователями, если это вообще возможно. Модель провайдеров позволяет преодолеть этот фундаментальный стандарт разработки приложений с открытым кодом. Она также обеспечивает новый уровень абстракции между слоем доступа к данным и хранилищем данных.

DNN и ASP.NET 2.0

Для того чтобы создать приложение, которое полностью поддерживает аутентификацию в ASP.NET 2.0, в DNN был интегрирован провайдер членства. Это дало ряд преимуществ:

Порталы и приложения

DNN поддерживает возможность создания нескольких порталов в одной инсталляции DNN. Каждый портал имеет своих собственных пользователей и роли, которые не пересекаются с пользователями и ролями других порталов. Портал идентифицируется уникальным ключом - PortalID.

Поскольку используемая по умолчанию реализация провайдера членства компании Microsoft является общим, универсальным решением, она не поддерживает концепцию множественности порталов, каждый из которых имеет собственных пользователей и роли. Реализация, используемая по умолчанию, была разработана с учетом возможности поддержки только одного портала в экземпляре DNN. Провайдер членства рассматривает экземпляр DNN как приложение, и без дополнительной настройки это приложение может поддерживать только один набор пользователей и ролей.

Для преодоления этого ограничения требуется специальный упаковщик (wrapper), располагающийся между провайдером данных и провайдером членства. Эта настройка позволяет приложению DNN получить поддержку виртуализации. В конечном результате провайдер членства, реализованный в DNN, может поддерживать многочисленные приложения (несколько порталов в одном экземпляре DNN).

При использовании модели провайдеров информация о пользователях может храниться отдельно от основного информационного хранилища DNN.

Администратор портала

При создании портала автоматически создается новый пользователь, который автоматически ассоциируется с ролью безопасности Administrator и становится администратором портала по умолчанию. Административные привилегии могут также делегироваться другим пользователям. В идеале, по соображениям безопасности, учетная запись администратора должна не ассоциироваться с физическим пользователем, а использоваться только для создания новых учетных записей конкретных пользователей, которые и будут выполнять административные функции.

Администратор сайта имеет полный контроль над формированием и поддержкой своего сайта. Он имеет способность редактировать весь контент и страницы в пределах сайта.

Администратор имеет также полный доступ к изменению всех настроек сайта. Это включает роли управления файлами, управления учетными записями пользователей, управление провайдерами, роль доступа к регистрации на сайте, рассылку информационных писем, отображение журнала регистрации, управление языками и шаблонами оформления.

Администратор имеет полный доступ к Панели управления, а также страницам меню Admin.

Регистрация пользователей портала

DNN предоставляет возможность регистрации пользователей портала. В результате процесса регистрации анонимные пользователи могут присоединятся (или подавать заявку на присоединение) к роли Registered Users и получать доступ к привилегированным разделам контента или его особой функциональности.

Поскольку роль Registered Users требует проведения процедур регистрации и аутентификации, эти функции объединяются в различные варианты процесса регистрации, один из которых можно выбрать на странице Admin | Site Settings (рис. 13.2).

Тип регистрации зависит от функциональных потребностей пользователей сайта. В перечислены возможные варианты и их влияние на поведение сайта.

Администратор может настраивать текст приветственного письма, высылаемого пользователям в ходе регистрации.

Практические задания

Выбор способа регистрации пользователей

Для выбора способа регистрации пользователей на сайте следует зарегистрироваться на портале под пользователем с правами администратора или хоста. Далее необходимо выбрать пункт меню Admin | Site Settings. Требуемый параметр - Security Settings - находится в группе параметров Advanced Settings (рис. 13.2). В данной работе выберем способ регистрации Public.

Самостоятельная регистрация пользователя

Для того чтобы рассмотреть процедуру регистрации, которую будут проходить пользователи портала, необходимо выйти из административного режима работы с порталом в гостевой. Для этого в левой верхней части сайта служит ссылка Выход - Logout (рис. 13.3).

В гостевом режиме в том же самом регионе сайта находится ссылка "Регистрация", выбор которой приводит к началу регистрации пользователя на портале. Пользователю необходимо указать имя учетной записи, которую он желает использовать, свои имя и фамилию, его отображаемое имя (возможно, псевдоним), адрес электронной почты и пароль (рис. 13.5).

В том случае, если используется режим регистрации Verified, в поле "Адрес электронной почты" следует указывать адрес реального почтового ящика. В противном случае будет невозможно получить доступ к письму с верификационным кодом. В данной лабораторной работе используется режим регистрации Public, поэтому можно указывать произвольный адрес. Создадим пользователя "Иванов Иван", с именем пользователя ivanov. После указания регистрационных данных будет осуществлен автоматический вход пользователя на сайт.

Создание пользователей администратором

Учетные записи пользователей может также создавать администратор сайта. Для этой цели служит страница User Accounts (рис. 13.6), открывающаяся при выборе пункта меню Admin | User Accounts.

В верхней части страницы находится поле Search, предназначенное для поиска пользователя по различным атрибутам, которые выбираются из раскрывающегося списка. Имеется также возможность отображения списка пользователей по первой букве имени учетной записи, всех пользователей (All), находящихся в данный момент на сайте (Online) и ожидающих авторизации (Unauthorized). Выберем ссылку All, чтобы просмотреть полный список пользователей (рис. 13.7).

Для добавления нового пользователя служит ссылка Add New User. При ее выборе открывается окно, аналогичное отображаемому при самостоятельной регистрации пользователя (рис. 13.7). Создадим пользователя "Петров Петр", с именем пользователя petrov.

Создание привилегированных разделов сайта

Для получения сведений о пользователях, пользующихся услугами сайта, необходимо вынудить их пройти процедуру регистрации. Сделать это можно, закрыв гостевой доступ к части разделов сайта, содержащих интересную информацию, и предоставив доступ только для зарегистрированных пользователей. Осуществляется это путем модификации атрибутов видимости одной страницы или их группы. Измененные атрибуты видимости применяются как к выбранной странице, так и к тем страницам, которые находятся ниже нее по иерархии. Изменим область видимости страницы "Турпоездки", что должно также повлиять на страницы "Поле" и "Пляж". Для этого следует зайти на сайт с правами администратора и выбрать пункт меню Admin | Pages. На открывшейся странице "Страницы" (рис. 13.8) следует выбрать страницу "Турпоездки" и нажать кнопку - "Изменить свойства выбранной страницы".

Откроется страница "Управление страницами" (рис. 13.9).

На этой странице следует убрать флажок "Все пользователи" в столбце "Просмотр страницы" и поставить флажок "Registered Users" в том же столбце. Кроме того, следует выбрать ссылку "Копировать разрешения", чтобы задать выбранные разрешения для подчиненных страниц.

После проделанных операций указанные выше страницы перестанут быть видны незарегистрированным пользователям.

Контрольные вопросы