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

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

• DomainModel : объекты домена и интерфейсы для репозиториев
• AppService : службы приложений, средства отображения моделей просмотра, сообщения и т. д.
• Репозитории : EF Repository, XML Repository, Stub Repository
• Презентация : реализует шаблон MVP (представления, презентаторы, интерфейсы)

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

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

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

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