Членство в ASP.NET и безопасность на основе ролей

Question

Я разрабатываю движок для блогов с ASP.NET & C#. Основное решение состоит из нескольких проектов, перечисленных ниже

• DomainModel: доменные объекты и интерфейсы для репозиториев
• AppService: сервисы приложений, просмотр карт моделей, сообщения и т. Д.
• Repositories: репозиторий EF, репозиторий XML, репозиторий-заглушка
• Presentation: реализует шаблон MVP (представления, докладчики, интерфейсы)

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

Прежде всего, требуется только учетная запись пользователя ID из базы данных членства в базе данных блога. И наконец, в проекте пользовательского интерфейса должна быть реализована ролевая безопасность. Так как я довольно новичок в разработке распределенных приложений, DDD и прочем, я хотел знать, является ли реализация безопасности на основе ролей просто обязанностью приложения пользовательского интерфейса, или есть другие вопросы, о которых нужно позаботиться в другом слои раствора. Насколько я знаю на данный момент, только представления (веб-страницы) должны реализовывать безопасность на основе ролей, отображать различное содержимое и предлагать различные функции в зависимости от текущего сеанса. но это все?

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

• Является ли реализация безопасности просто обязанностью приложения пользовательского интерфейса?
• Могу ли я настроить / изменить дизайн моей доменной модели и / или других уровней, чтобы реализация безопасности на основе ролей была проще и не зависела от приложения пользовательского интерфейса полностью.
• Является ли хорошей идеей учитывать безопасность на других уровнях, чтобы уровень пользовательского интерфейса был просто представлением данных и средой между пользователем и системой.

Answer 1

Безопасность - это междисциплинарная проблема: в нее вовлечены пользовательский интерфейс, уровни приложений и доменов.Насколько я понимаю, вы имеете дело с такими правилами, как "Только автор может редактировать блог" или "Только зарегистрированные пользователи могут оставлять комментарии".В этом случае пользовательский интерфейс должен знать эти правила, чтобы решить, отображать ли ссылки «Редактировать» или «Комментарий».Доменные объекты должны иметь возможность применять эти правила.

Насколько я знаю, членство в ASP.NET делает много вещей, включая хранение пользователей, аутентификацию, авторизацию и управление ролями.Однако он не знает о вашем домене.Он не знает, что такое блог.Он знает, что такое ASP-страница.Поэтому, если вы не хотите выражать свои доменные правила в качестве правил доступа к странице, вы можете провести толстую линию между вашим приложением и членством в ASP.NET.Возможно, вы захотите делегировать пользовательское хранилище и аутентификацию ASP.NET, но сделайте все остальное самостоятельно.Также может быть хорошей идеей не иметь прямой зависимости от ASP.NET в вашем доменном модуле.Вы также хотите подумать о том, как будет работать членство в ASP.NET, если впоследствии вы решите перейти с веб-форм на MVC или если у вас будет веб-API для механизма ведения блогов.

Answer 2

Не уверен, что именно вам нужно, но стоит отметить, что стандартный PrincipalPermissionAttribute Class прекрасно работает с ролями ASP.NET, реализованными с помощью этой технологии провайдера.

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

Answer 3

Безопасность должна быть ответственностью всех приложений.Это действительно зависит от структуры вашего приложения.

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

Вы также получаете преимущества таким способом, если хотитеиспользовать вашу модель данных другими способами, например, через веб-службы или из другого приложения, например Silverlight.

Обновление

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

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

Способ его реализации будет зависеть от того, как вы написали свое приложение.Я бы сказал, что лучший способ - создать слой абстракции между вашим приложением и участником asp.Вы получаете все преимущества, которые вы уже знаете, например, тестирование, изменение архитектуры и т. Д.

Одной из вещей, о которой вы можете подумать, является концепция прав или разрешений.В ASP нет собственных библиотек, чтобы справиться с этим, поэтому вам придется свернуть свои собственные.Каждый раз, когда вы хотите что-то сделать, вы проверяете, что пользователь имеет право.Эти права могут быть свернуты в роли, которые в свою очередь могут быть назначены пользователям или группам пользователей.Вы получаете детальный контроль над тем, что могут делать пользователи, и это позволяет легко добавлять новые роли в будущем.

Answer 4

Поработав над этой проблемой некоторое время, я пришел к следующему выводу:

Реализация безопасности, такой как Authentication, Role-based security, Authorization и т. Д. В User-Уровень Layer не является хорошей идеей в основном по двум причинам:

1. Если вы хотите создать другие интерфейсы для своего приложения, скажем, WinForms или Silverlight, то выМне придется снова и снова внедрять эту защиту с нуля.
2. Вы всегда можете использовать другие компоненты / слои вашей системы, не создавая приложение пользовательского интерфейса.Предположим, вы создали простое консольное приложение, которое ссылается на другие слои в вашей системе (например, Repositories).тогда вы можете создать экземпляр хранилища и манипулировать данными.в этом случае вы успешно переопределили любую защиту.

Таким образом, решение состоит в том, чтобы внедрить этот тип защиты в другом уровне, который встроен в саму модель домена и не привязан к пользовательскому интерфейсу.layer (UI).

Теперь есть некоторые варианты того, как вы можете это сделать.скажем, у нас есть слой с именем AppService, который является точкой входа во всю систему.этот слой состоит из сообщений (шаблон обмена сообщениями, например, шаблон Request-Response), ViewModels, которые являются плоскими представлениями объектов домена, и Methods for retrieving and manipulating data и т. д. Здесь мы можем реализовать такие меры безопасности с помощью объектов PrincipalPermission.мы можем применять правила безопасности к классам и методам.Вот простой пример:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
public void DoSomething()
{ }

С атрибутом, определенным для этого метода, код требует аутентификации вызывающей стороны.Модель аутентификации может быть любой, включая Windows Authentication, Forms Authentication и так далее.теперь это работает нормально, потому что теперь мы слабо связали пользовательский интерфейс с правилами безопасности, определенными на уровне сервиса.однако есть еще одна загвоздка.

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

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

Другое дело, что с использованием правил PrincipalPermissionна ваших классах и методах не привязан к конкретной модели аутентификации / авторизации.так что вы можете использовать такие правила безопасности в веб-приложениях с Forms Authentication или в приложениях Windows с Windows/AcctiveDirectory Authentication и т. д.

Как вы помните, я разрабатываю простой движок для блогов на ASP.NET и эту модельработает нормально на данный момент.Если есть более подробные подробные сведения о плюсах и минусах, или примеры и сообщения в блогах, которые могут помочь в этой теме, пожалуйста, обязательно оставьте свои комментарии и ответы [: