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

Я рекомендую пойти с изменение «Подход № 1» — неиерархический Роли.

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

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

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

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

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

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

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

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

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

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

Съешь свой торт и съешь его тоже

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

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

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

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

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

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

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

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