Как лучше всего обработать полномочия (не роли) в членстве asp.net, конкретно в ASP.NET MVC
Существует много вопросов (и информация) при установке членства asp.net, ролевых поставщиков и т.п.. Необходимо ли использовать созданный в платформе, обеспеченной Microsoft, или роль расширяет базовые классы и роль собственное.
Я решил расширить поставщиков по умолчанию и реализовать моих собственных поставщиков членства и роли. Теперь мой вопрос, конкретно вокруг ролевой аутентификации.
Традиционно, Вы создали бы роли, возможно, как 'менеджер, Администратор, Сотрудник, Суперпользователь' или независимо от того, что Вы имеете. Но что/должно, Вы делаете относительно полномочий, которые я считаю более прекрасной мелкой частицей управления? Позвольте мне уточнить....
В рамках моего asp.net mvc сайт у меня есть различные области как администрирование, управление, обмен сообщениями, сообщая и т.д. Я упаковал бы роли в ящики для каждого из них, любят 'Администратора', 'менеджера', 'Генератор отчетов' и т.д. Без соответствующей роли Вы не можете получить доступ к той области сайта. Таким образом, я заблокировал бы вниз все контроллеры с этим на уровне класса.
Но теперь возьмите одну область в качестве примера; обмен сообщениями, и говорит, что я хотел иметь более прекрасные гранулярные полномочия для CRUD; создайте сообщение, просматривайте/читайте сообщения, отредактируйте сообщения, удалите сообщения и т.д.
Наконец мой вопрос. Как было бы лучше реализовать эту более прекрасную мелкую частицу управления? Один подход, который я вижу (не уверенный, если это - хорошее), должен просто создать роли членства asp.net для всего. Таким образом, я мог бы иметь....
Messenger (широкая роль уровня), CreateMessage, ReadMessage, EditMessage, DeleteMessage.
С одной стороны я хотел бы, чтобы некоторые пользователи смогли читать/просматривать сообщения. Но не обязательно создают или удаляют их. Действиям отдельного контроллера можно было применить определенные роли.
Вы видите какие-либо проблемы с этим подходом? У Вас есть лучшая идея?
Решение до сих пор
Я решил создать свою собственную схему и реализовать пользовательских поставщиков членства и роли. Моя схема включает;
- Пользователь
- UserProfile
- Разрешение
- PermissionAssignment
- Роль
- RoleAssignment
Попытка находиться далеко в течение следующего дня или два, но обновит с большей информацией, когда я получу шанс.
3 ответа
Я думаю, вам следует забыть о ролях в механизме авторизации, вместо этого запрашивать разрешения (в конце концов, роль - это совокупность разрешений), поэтому, если вы посмотрите на это таким образом, ваш 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()
Таким образом ваши роли будут делать то, что они умеют лучше всего, абстрактную коллекцию разрешений вместо определения негибкого способа уровня доступа.
РЕДАКТИРОВАТЬ: Для обработки определенных правил, подобных тому, что указал Дэвид Роббинс, менеджеру A не разрешено удалять сообщения, созданные менеджером B, при условии, что они оба имеют необходимое разрешение для доступа к этому действию контроллера, авторизация не отвечает за проверку правил этого типа, и даже если вы попытаетесь проверить, что на уровне фильтра действий это будет проблемой, поэтому вы можете расширить проверку авторизации до ActionResult (введя параметр действия, содержащий результат проверки), и пусть ActionResult принимает логическое решение со всеми аргументами.
Это похожий вопрос, это не совсем тот случай, который здесь указан, но это хорошая отправная точка для расширения проверки авторизации с помощью параметров действия.
А также добавить [Authorize(Roles="Administrator")] и т.д. над вашим контроллером. Вы также можете поместить этот атрибут на отдельные действия тоже
Что касается вашего примера CRUD, разве вы не говорите об авторизации, и будет ли авторизация варьироваться между ролями членства «Менеджер» и «Репортер»? Я думаю, вам нужно создать отдельный механизм для этих более тонких действий, если роли не различают авторизацию чтения и записи между сообщениями.
Если бы вам нужно было создать роль для каждого действия - EditMessage, DeleteMessage - что вы будете делать в случае, когда менеджер A НЕ должен иметь возможность удалять сообщения для менеджера B?