Теория/ресурсы иерархических групповых разрешений?

В руководстве по CakePHP есть отличное описание того, как работают списки контроля доступа.

http://book.cakephp.org/2.0/en/core-libraries/components/access-control-lists.html

Представлять набор разрешений для данной группы в виде битовой маски. Объединение битовых масок с помощью операции ИЛИ даст вам результирующий набор разрешений.

Обновление для @Alex:

Я написал этот ответ 3 года назад, но я полагаю, что имел в виду следующее...

Из вопроса

иерархия вложенных групп. Каждой группе можно разрешить/запретить доступ на чтение, запись, добавление и удаление (либо явно для этой группы, либо неявно одним из ее родителей). Как будто это было недостаточно сложно, система также позволяет пользователям быть членами нескольких групп. -- Тут я застрял. У меня все настроено, но я борюсь с фактической логикой определения разрешений для данного пользователя.

Назначьте битовую маску, соответствующую общему набору разрешений группы (или роли) в системе:

например 00 (использование двух битов упрощает задачу!)

Первый бит соответствует Permission A, а второй Permission B.

Теперь предположим, что Группа А предоставляет следующий набор разрешений: 01.

... и скажем, что группа B предоставляет следующий набор разрешений: 10.

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

Permission set for Group A   01
Permission set for Group B   10 OR 
                             ----
Resultant permission set     11 (i.e. both permission A and B are conferred)

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

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

Изменить: вот лучшая ссылка на документацию AFS:

http://www.cs.cmu.edu/~help/afs/index.html

Вот раздел о группах:

http://www.cs.cmu.edu/~help/afs/afs_groups.html

Я делал именно это раньше, и это не тривиальная реализация. Вы захотите взглянуть на класс SecurityPermission.

[http://msdn.microsoft.com/en-us/library/system.security.permissions.securitypermission.aspx][1]

Я делал это раньше, используя XML (что я не уверен, что буду делать снова) и сохраняя этот XML в качестве списка разрешений внутри SQL-сервера в столбце XML через хранимую процедуру CLR. XML будет иметь элемент, называемый «разрешение», а затем разрешение будет фактически ENUM внутри кода. Каждое разрешение было новой реализацией класса SecurityPermission (ссылка выше). Пользователи были привязаны к группам, которые были определены на сервере SQL, а затем, когда пользователь добавлялся/удалялся из групп, XML-документ обновлялся, чтобы отразить, какие группы они разделяли. из.

Как только пользователь войдет в систему, учетные данные пользователя будут загружены в хранилище приложений (сеанс), а затем будут соответствующим образом доступны. Когда требуется авторизация, XML в магазине приложений загружается в SecurityPermission с помощью метода «FromXML». В этот момент я бы использовал следующие методы, чтобы определить, есть ли у пользователя разрешение:

• Требовать
• Пересекать
• Союз
• IsUnrestricted
• Иссубсетоф

и т. д., и т. д., и т. д.

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

Опять же, это упускает ТОННУ деталей, но это должно направить вас по правильному пути.

Взгляните также на это пространство имен: [2]: http://msdn.microsoft.com/en-us/library/system.security.permissions.aspx "System.Security.Permissions"