Сообщество русскоговорящих пользователей
CMS DotNetNuke
   Вы здесь:  База знаний » Статья
07.11.2009 13:00:40, Administrator
Система безопасности DotNetNuke – Часть 1

Безопасность в 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. API провайдера данных не имеет никаких сведений о том, какой тип источника данных будет использоваться, до тех пор, пока он не будет сконфигурирован в файле web.config. Может использоваться любой источник данных, обеспечивающий необходимую функциональность.

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

Использование провайдера данных в 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.

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

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

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

Вариант Описание
None (нет) Регистрация для посетителей сайта невозможна. Кнопка login остается видимой, чтобы предоставить доступ к административным функциям, кнопка Registration скрывается. Этот вариант предназначен для сайтов, на которых не публикуется привилегированный контент, или процесс регистрации производится администратором, по данным, передаваемым ему в режиме "офф-лайн".
Private (Частная) Регистрирующиеся подают заявку на регистрацию. Пока заявка не будет подтверждена администратором, их привилегии аналогичны привилегиям анонимных пользователей. Этот вариант подходит для таких сайтов, как, например, личный сайт семьи, на котором регистрируются друзья и знакомые. Потенциальным пользователям сайта рассылаются письма с приглашением пройти регистрацию. После подтверждения регистрации высылается еще одно письмо. В данном случае рекомендуется описать процедуру регистрации на одной из страниц сайта.
Public (Публичная) Регистрация автоматически и немедленно проходит процедуру авторизации без проверки адреса e-mail. На указанный ящик высылается письмо с приветственным сообщением. Этот вариант подходит для сайтов, которые отслеживают сведения о пользователях, но не требуют подтверждения введенной ими регистрационной информации.
Verified (С подтверждением) В ходе процедуры регистрации генерируется верификационный код, который включается в приветственное письмо, высылаемое на указанный пользователем адрес. Авторизация происходит в момент первого входа пользователя, когда он указывает верный верификационный код. Этот процесс гарантирует, что пользователи укажут верный почтовый адрес.

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

Автор: В.В. Полубояров Источник: www.intuit.ru
powered by metaPost
print



rating
  Комментарии

Нет комментариев.

 
OpenedBorderBoxed Small width layoutMedium width layoutMaximum width layout Small textMedium textMaximum text