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

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

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

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

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

• элементы управления входом пользователя и учетными данными пользователя: новый набор элементов управления устраняет потребность в самостоятельном написании стандартного кода для каждого приложения. Имеется возможность создания набора страниц для регистрации нового пользователя, входа зарегистрированного пользователя, отсылки пользователю забытого пароля путем размещения на странице соответствующих элементов управления и настройки нескольких их свойств.
• управление пользователями: к каждому приложению ASP.NET 2.0 можно получить доступ с использованием специального набора административных страниц, которые позволяют авторизированному пользователю создавать новых пользователей, присваивать им роли и хранить информацию о пользователях. К этим функциям имеется доступ при помощи специального API, поэтому существует возможность создания собственных инструментов управления. Описываемая технология, ASP.NET Web Configuration, может быть использована только в среде разработки, что предполагает необходимость разработки собственных решений для среды внедрения.
• провайдер членства/ролей: функция членства создает связь между конечными функциями (элементами управления входом пользователя и управлением пользователями сайта) и механизмом хранения. Провайдер членства инкапсулирует весь код доступа к данным, который требуется для хранения и получения информации о пользователях и их ролях. Благодаря модели провайдеров, этот компонент может быть заменен провайдером, поддерживающим требуемый источник данных.

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

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

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

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

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

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

• провайдер данных;
• провайдер планировщика;
• провайдер журналирования;
• провайдер HTML-редактора;
• провайдер поиска;
• провайдер дружественных URL.

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

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

Рис. 13.1. Использование провайдера данных в DNN

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

DNN и ASP.NET 2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 13.2. Варианты регистрации пользователей

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

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