Иерархический доступ на основе ролей/разрешений

Я рекомендую использовать вариант "Подхода №1" - неиерархические роли.

Я работал с подобными системами с большим успехом. Хотя на первый взгляд этот подход может показаться «менее структурированным», он относительно прост и очень гибок; когда разрешено несколько ролей для каждого пользователя и определены правила для агрегирования разрешений.

Против иерархий (для ролей)

Подобно «ОО-иерархии», использование иерархии ролей приводит к строгим отношениям замещения. Это усложняет определение ролей на основе меняющихся требований.

Например, возможно, в будущем потребуется учетная запись «Администратор», которая не может создавать свои собственные сообщения. Иерархия (и отношение замещения) предотвращает это без изменения самой древовидной структуры, потому что «Полный администратор» — это «Платный пользователь».

Запросы к истинной иерархии в SQL более сложны; особенно в реализациях, не поддерживающих рекурсивные запросы, таких как MySQL. Переключение на иерархию с использованием вложенного набора или материализованного подхода приводит к дополнительной структуре, а не только к отношению родитель-потомок.

Вам это просто не нужно; чем сложнее программное обеспечение, тем сложнее его писать и поддерживать. Хотя иерархии очень хороши в некоторых случаях — например, в спецификации материалов, генеалогии или структуре каталогов — в большинстве моделей ролей/групп-разрешений просто нет «необходимости».

Для (несколько) ролей

Роли без зависимости от «родительского типа» функционируют скорее как «объектно-ориентированные интерфейсы» — ну, может быть, Trait композиция была бы более подходящей, если бы аналогии были растянуты. Реализация (читай: предоставленные разрешения) каждой роли может изменяться независимо от любой другой роли, что делает ее чрезвычайно гибкой. Как и в случае с интерфейсами, одному пользователю/сущности может быть назначено более одной роли.

Запросы к плоской модели User <M-M> Role <M-M> Permission намного проще в SQL (с рекурсивной поддержкой или без нее или с дополнительной структурой), потому что просто нет иерархии ролей для обхода.

Группы ACL Windows (давайте проигнорируем вложенные группы) работают так же, как Роли; Пользователь принадлежит к одной или нескольким группам, которые предоставляют (или отклоняют, но это другая ситуация) разрешения.

Возьми свой торт и съешь его тоже

Вариант, который я рекомендую и о котором упоминалось выше, заключается в разрешении агрегирования разрешений между ролями. Простая модель агрегации такова:

• Пользователь имеет объединение разрешений от всех назначенных ему ролей.

  (Действующие разрешения, как правило, создаются во время авторизации, но без иерархии также относительно просто выполнять запросы в SQL.)

Таким образом, разрешения привязаны к каждой роли с небольшим перекрытием или без него, как показано в «Подходе № 2», с той разницей: Иерархия отсутствует.

Например, чтобы разрешить специальному администратору выполнять поиск сообщений (и удалять «плохие» сообщения), можно просто назначить «Обычный пользователь» и «Ограниченный администратор». " Роли¹.

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

¹ Это не очень хороший пример. На самом деле роли должны иметь разные имена (например, «Поддержка учетной записи» или «Модератор контента») и охватывать разные наборы разрешений; они, вероятно, со временем изменятся на основе проб и ошибок и бизнес-правил «вкус месяца».

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