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

Я хочу построить иерархический контроль доступа к базе ролей. Это моя текущая схема:
enter image description here

В настоящее время у меня есть два варианта построения этой системы:

  1. прикрепить все необходимые разрешения для роли (не-иерархические) enter image description here

  2. прикрепить только специальные разрешения" уровня " и наследовать те, которые имеют более низкие уровень enter image description here

есть ли лучший подход или просто зависит от моих потребностей проекта?

Я склонен выбирать иерархический только из-за простоты. Если я это сделаю, есть ли лучший способ выбора уровней разрешений, возможно, с помощью двоичных чисел?

Вариант 2 будет иметь некоторые уровни для ролей, и у меня будут номера уровней для разрешений. Поэтому, когда я создаю Full Administrator роль унаследует все другие разрешения, так как это будет Уровень 4, а другие разрешения будут иметь число меньше, чем Уровень 4 (или 4000).

это перебор?

7
hierarchical mysql permissions php role-based-access-control

1 ответов

Я рекомендую пойти с вариация "подход #1" - неиерархических роли.

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

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

как "иерархия OO", используя иерархия ролей приводит к строгой подстановке отношений. Это затрудняет определение ролей на основе изменяющихся требований.

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

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

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

для (мульти) роли

роли, без зависимости "родительского типа", функционируют больше как "интерфейсы OO" - ну, может быть признака состава было бы более уместно, если аналогии будут растянуты. Реализация (чтение: предоставленные разрешения) каждой роли может измениться независимая любой другой роли, что делает его чрезвычайно гибким. И, как и интерфейсы, более одной роли может быть назначена данному Пользователь / сущность.

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

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

есть торт и съесть его Слишком!--12-->

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

  • пользователь имеет объединение разрешений от все роли, которые они назначены.

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

таким образом, разрешения привязаны к роли с небольшим или без перекрытия, как показано в "подходе #2", с этой разницей: Иерархии Нет.

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

С помощью неиерархических система multi-роли способная позволяет этому чисто, shrugging с тяготы иерархии, пока все еще обеспечивающ гибкие/composable/конфигурируемые архетипы роли.

1 это не особенно хороший пример. На самом деле роли должны иметь разные названия (например. "Поддержка учетной записи "или" модератор контента") и охватывают различные наборы разрешений; они, вероятно, будут меняться с течением времени на основе проб и ошибок и вкуса месяца бизнес правила.

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

7