Я немного опоздал с игрой для этого, но вы могли бы взглянуть на то, как CakePHP выполняет свою авторизацию. (Если вы используете PHP, вы можете обнаружить, что использование инфраструктуры CakePHP дает вам часть этого элемента управления без необходимости его кодирования.)
пользовательские разрешения-и-CakePHP
Кроме того, я считаю полезным хранить список действий (например, CRUD или Admin) для сущностей, чтобы вы, кроме обычной таблицы «пользователь / пароль», имели бы таблицу с полями в виде ниже.
PermID | Deny or Allow | Action | Entity
Затем у вас есть другая таблица, которая отображает группы в PermId, и другая таблица, которая отображает пользователей и группы (рекурсивно, если необходимо) в группы (о чем люди уже говорили).
Запретить или разрешить означает, что вы можете создавать списки ACL для разрешения использования или DACL для запрета использования, если по умолчанию разрешено действие (что, как правило, обычно не лучшая идея), или если есть небольшая группа, которая имеет будет отказано в доступе в более крупном. Обычно вы сначала проверяете наличие явного Запрета на действие против сущности для группы / пользователя.
Так что у вас может быть что-то вроде:
PermID | Type | Action | Entity
-------+-------+---------+------------
1 | Allow | Read | User_Entry
2 | Allow | Delete | User_Entry
3 | Allow | Move | User_Entry
4 | Allow | Approve | User_Entry
5 | Allow | Create | User_Entry
Таким образом, в качестве иллюстрации, группа администраторов может отображаться на записи 1-5, а группа «обычного пользователя» может отображаться только на 1 и 5. (Для группы прочитайте «персона» или «пользователь», если хотите).
Id | Grp | PermId
---+--------+-----
1 | Admin | 1
2 | Admin | 2
3 | Admin | 3
4 | Admin | 4
5 | Admin | 5
6 | Normal | 1
7 | Normal | 5
Очевидно, что это легко расширяется, поскольку, когда в системе возникает новое действие или сущность (например, каталог), это просто случай добавления соответствующих записей в таблицы без необходимости изменения схемы. Например, вы можете использовать действия «Все» и использовать DACL для определенного исключения. Вот опытный пользователь, который может делать все, кроме удаления User_Entry.
PermID | Type | Action | Entity
-------+-------+---------+------------
6 | Allow | All | User_Entry
7 | Deny | Delete | User_Entry
Id | Grp | PermId
---+--------+-----
8 | Power | 6
9 | Power | 7
В вашем случае я представляю, что сущности могут включать название группы или какой-либо токен, который будет означать «ваша домашняя группа», или что-то напр. {homegrp} / UserEntry, а не просто UserEntry, который может иметь системный администратор.
Извините, если это было немного глупо, но я надеюсь, что вы поняли суть этого. (Извиняюсь, если в каком-либо предыдущем ответе говорилось об этом, так как я не думаю, что прочитал все до конца ...)