Как лучше всего справляться с разрешениями (не ролей) в членов ASP.NET, в частности в ASP.NET MVC

Question

Есть много вопросов (и информация) при настройке членства ASP.NET, поставщиков ролей и тому подобное. Независимо от того, следует ли использовать встроенные платформы, предоставляемые Microsoft, или роль расширяет базовые классы и роль собственного собственного.

Я решил продлить поставщиков по умолчанию и внедрить мое собственное членство и поставщики ролей. Теперь мой вопрос, специально для аутентификации роли.

Традиционно вы создадим роли, может быть, как «менеджер, администратор, сотрудник, супер пользователь» или что у вас есть. Но что бы / ты должен сделать в отношении разрешений, которые я считаю более тонкой зерном контроля? Позвольте мне уточнить ....

В моем сайте MVC ASP.NET у меня есть разные области, такие как администрирование, управление, обмен сообщениями, отчетность и т. Д. Я бы явидимся ролям для каждого из них, как «администратор», «менеджер», «репортер» и т. Д., Без соответствующей роли , вы не можете получить доступ к этой области сайта. Поэтому я бы заблокировал все контроллеры с этим на уровне класса.

Но теперь принять одну область в качестве примера; Обмен сообщениями и скажем, я хотел иметь более тонкие разрешения зерна для CRUD; Создайте сообщение, просмотр / чтение сообщений, редактирование сообщений, удаление сообщений и т. Д.

Наконец мой вопрос. Как лучше всего реализовать это более тонкое зерно контроля? Один из подходов я вижу (не уверен, если это хороший), это просто создать роли членства ASP.NET для всего. Так что я мог бы иметь ....

Messenger (роль широкого уровня), CreateMessage, ReadMessage, editmessage, deletemessage.

С одной стороны, я хотел бы, чтобы некоторые пользователи могли читать / просматривать сообщения. Но не обязательно создавать или удалять их. Индивидуальные действия контроллера могут иметь применяемые конкретные роли.

Видишь ли вы какие-либо проблемы с этим подходом? У вас есть лучшая идея?

Решение до сих пор

Я решил создать свою собственную схему и внедрить пользовательские члены и поставщики ролей. Моя схема включает в себя;

.
• user
• userprofile
• разрешение
• Перепродача
• Роль
• reoorassignment

будет отсутствие на следующий день или два, но обновит с большим количеством информации, когда у меня есть шанс.

Answer 1

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

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

.

Таким образом, ваши роли делают то, что они делают лучшие, абстрактные разрешения, а не определение негибкого способа доступа уровня доступа.

Редактировать: для обработки конкретных правил, как тот, который, ориентированный на David Robbins, менеджер A запрещено удалять сообщения, созданные Manager B, предположить, что они оба имеют необходимое разрешение на доступ к этому действию контроллера, Уполномоченный не несет ответственности за проверку этого типа правил, и даже если вы попытаетесь проверить, что на уровне фильтра действий это будет боль, так что вы можете сделать, это расширить авторизованную проверку на ActionResult (впрыскивая параметр действия, удерживающий Результат проверки), и пусть ActionResult делает логическое решение там со всеми аргументами на месте.

это Подобный вопрос, не совсем так, не указано здесь, но это хорошая отправная точка при расширении проверки авторизации с параметрами действия.

Answer 2

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

Если вы должны были создать роль для каждого действия - editmessage, deletemessage - что вы будете делать в случае, когда менеджер A не должен удалить сообщения для менеджера b?

Answer 3

, а также добавление [Authorize(Roles="Administrator")] и т. Д. выше вашего контроллера.Вы также можете поставить этот атрибут на индивидуальные действия тоже