ASP.NET MVC 3 - Особенности архитектуры безопасности

Question

Я исследую основы безопасности для приложения ASP.NET MVC3, в котором были бы довольно сложные правила авторизации с точки зрения того, кто может просматривать данные, кто может их создавать и редактировать.Правила, такие как - я могу видеть только клиентов, которые являются частью моей компании или филиала.- Если я пропущу 15 дней или меньше с того дня, когда была создана запись, и моя роль принадлежит суперпользователю, то только я могу редактировать все поля этой записи, кроме двух.Через 16 дней и более я могу редактировать только два поля.

Сначала я хотел использовать блок безопасности предприятия и просто добавить настраиваемые авторизаторы, но после прочтения дополнительной информации о собственной поддержке безопасности на основе членства в ASP.NET.Я не уверен, нужен ли Enterprise Security Block.Я не использовал ни один из фреймворков в реальном приложении, поэтому ищу какую-то коллективную мудрость по этой теме.

Answer 1

Вы можете использовать Azman - Microsoft Authorization Manager и связанные с ним API.

Он предоставляет вам роли, действия, разрешения и многие другие настраиваемые параметры.

Azman использует AD для хранения большей частиэтот.Он также предоставляет опции для хранения с использованием локальных XML и / или файлов конфигурации.

Answer 2

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

Затем вам нужно выяснить, что означает «разрешить» в вашем интерфейсе.Отключить это?Скрыть?игнорируй?

Я тебе не завидую.

Тебе это может показаться полуинтересным.

http://bartreyserhove.blogspot.com/2008/12/field-level-security-using-aspnet-mvc.html

Answer 3

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

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

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

Answer 4

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

Я не знаю каких-либо фреймворков, которые дадут вам это по умолчанию, так как это очень нестандартные правила редактирования. Вы могли бы вызывать эти утверждения, и при входе в систему вы должны использовать платформу, основанную на утверждениях, такую ​​как основы идентификации Windows (WIF), но вам все равно понадобятся пользовательские значения IF, чтобы разрешить редактирование в вашем представлении на основе свойств, установленных в ViewModel, таких как CustomerViewModel.AllowAddressEdit , Ваше представление должно затем проверить это свойство, чтобы отобразить DisplayFor или EditorFor. Однако вы должны также проверить эти значения при обратной передаче, чтобы убедиться, что пользователь не просто ввел значения, чтобы взломать ваше приложение.