Как лучше всего обрабатывать разрешения (не роли) в членстве asp.net, особенно в ASP.NET MVC - PullRequest
Новая
       50

Как лучше всего обрабатывать разрешения (не роли) в членстве asp.net, особенно в ASP.NET MVC

11 голосов
/ 21 июля 2010

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

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

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

На моем сайте asp.net mvc у меня есть различные области, такие как администрирование, управление, обмен сообщениями, создание отчетов и т. Д. Я бы выделил роли для каждой из них, такие как «Администратор», «Менеджер»., «Репортер» и т. Д. Без соответствующей роли вы не можете получить доступ к этой области сайта.Так что я бы заблокировал все контроллеры с этим на уровне класса.

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

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

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

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

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

Решение пока что

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

  • Пользователь
  • UserProfile
  • Разрешение
  • PermissionAssignment
  • Роль
  • RoleAssignment

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

Ответы [ 3 ]

5 голосов
/ 21 июля 2010

Я думаю, вам следует забыть о ролях в механизме авторизации, вместо этого запросить разрешения (в конце концов, роль - это набор разрешений), так что если вы смотрите так, ваш 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()

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

РЕДАКТИРОВАТЬ: Вобрабатывать определенные правила, такие как те, на которые указал Дэвид Роббинс, менеджеру А не разрешается удалять сообщения, созданные менеджером Б, при условии, что у них обоих есть необходимые разрешения для доступа к этому действию контроллера, авторизация не несет ответственности за проверку правил этого типа, идаже если вы попытаетесь проверить, что на уровне Action Filter это будет проблемой, то, что вы можете сделать, это расширить проверку Authorize на ActionResult (внедрить параметр действия, содержащий результат проверки), и позволить ActionResult принять логическое решение.со всеми аргументами на месте.

Этот является аналогичным вопросом, это не совсем тот случай, который указан здесь, но это хорошая отправная точка для расширения проверки Авторизации с помощью параметров действия.

2 голосов
/ 21 июля 2010

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

Если вы должны были создать роль для каждого действия - EditMessage, DeleteMessage -что вы будете делать в случае, когда диспетчер А НЕ сможет удалить сообщения для менеджера Б?

0 голосов
/ 21 июля 2010

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

...