Стратегия обработки разрешений приложений с использованием Entity Framework 4.1

Question

Во-первых, я использую EF 4.1 и использую шаблоны Repository и Unit Of Work. Мы создаем веб-приложение.

Я начинаю свой проект с использованием подхода Code First для EF 4. В данный момент база данных не существует. Поэтому я пытаюсь разработать стратегию обработки данных, к которым у пользователя есть доступ и где эта логика должна находиться в моей структуре.

Допустим, пользователь входит в систему и хочет создать пользователя для системы. Эта форма имеет поле, чтобы поставить нового пользователя в какую-то роль. Пользователь, которому поручено создать этого «нового пользователя», может видеть только определенные типы ролей (Пользователь, Создатель и Средство просмотра), но мы знаем, что роль администратора существует, но у этого пользователя нет доступа к ней. Когда я звоню в службу, чтобы предоставить мне этот список ролей, хочу ли я вернуть все роли обратно, а затем создать новый список на основе какого-то набора разрешений?

Я борюсь с идеей иметь некоторую эту логику в моем репозитории, но на самом деле не думаю, что она там подходит.

Answer 1

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

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

Например:

RoleID    Role
     1    Peon
     5    Common Folk
     10   King
     15   Supreme Master of the Universe

Так что, возможно, только короли и SMU могут добавлять новых пользователей. SMU могут создавать другие SMU, Kings, Common Folk и Peons. Короли могут делать то же самое, за исключением SMU. Пробелы в идентификаторах дают вам возможность добавлять больше ролей позже без перенумерации.

Answer 2

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

http://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute.aspx