Сергей Радкевич (level3@mail.ru, ICQ:15320127)
В данной работе рассматриваются способы хранения информации о правах доступа к различным частям программ и данных. Работа может быть интересна программистам, реализующим многопользовательские системы.
Термины
1. Пользователи, права, роли и группы
1.1. Набор прав
1.2. Группы пользователей
1.3. Ролевая модель
1.4. Модель с ролями и группами
1.5. Оптимизация
1.5.1. Маски прав
1.5.2. Эффективные права
2. Объекты
2.1. Права на объекты
2.2. Иерархии объектов
Заключение
При создании приложения, которое используют несколько пользователей, возникает задача ограничения доступа. Существует несколько способов решения этой задачи. Выбор оптимального способа зависит от дополнительных условий и особенностей приложения.
Самый простой способ ограничения доступа - когда есть список пользователей, которым разрешено работать со всей программой целиком. Для его реализации потребуется одна таблица с полем "пользователь". Проверке на входе в программу - единственная проверка.
В более сложном случае нужно разграничивать доступ к отдельным частям (функциям) программы и проверок становиться много, а не одна. Поэтому есть понятия:
Роли и группы могут быть использованы как дополняющие друг друга (ортогональные) концепции. Поэтому есть четыре варианта их применения: не использовать ни одну из них, использовать по только группировку пользователей, использовать только группировку прав, использовать группировку пользователей и прав одновременно.
В этом случае некоторому пользователю дается (или не дается) право выполнять некоторую операцию. Так как операции и пользователи связаны отношением "многие - ко - многим" здесь потребуются уже три таблицы: "пользователи", "операции", "пользователь имеет право на операцию".
В случае если программой пользуется большое количество пользователей, то назначать права каждому пользователю становится неудобно. Тогда вводят понятие "группа пользователей". Сначала пользователей объединяют в группы (например, на территориальной основе, по возрастному признаку, совершеннолетние - несовершеннолетние), а затем определяют права для групп. При этом при добавлении нового пользователя в систему вместо назначения ему прав достаточно просто добавить пользователя в нужную группу. Пользователи и группы в общем случае связаны соотношением "многие - ко - многим". При этом иногда возникает потребность запретить какое-то право отдельному пользователю группы. Кроме того, права могут назначаться как группам, так и отдельным пользователям. Для этого потребуется следующая структура:
Если у программы много функций, которые удобно логически сгруппировать, то вводят понятие "роль" - набор функций, необходимых для выполнения некоторой работы. Так, например, для программы автоматизации школы такими ролями могут быть "ученик", "учитель", "родитель", "завуч". Пользователь может иметь несколько ролей, например, быть одновременно учителем и родителем. Т.е. пользователи и роли связаны отношением "многие - ко - многим", так же как и пользователи и группы в схеме с группами пользователей. В обеих схемах можно не давать возможности назначать индивидуальным пользователям индивидуальные права. В этом случае потребуется такая схема:
Чтобы обеспечить максимальную гибкость для ограничения доступа ролевую модель и группы пользователей объединяют в общую модель. В этом случае роли могут назначаться группам, что еще уменьшает объем администрирования.
В итоге получается тетраэдр, в вершинах которого находятся пользователи, группы, роли и права, а на ребрах - таблицы для моделирования отношения "многие - ко - многим"
1.5.1. Маски прав
Если прав фиксированное количество, то можно завести в таблицах "пользователь-право", "группа-право" и "роль-право" дополнительные поля, например по одному полю на каждое право. Тогда таблицу "право" можно сделать подразумеваемой. Если прав меньше 32, то можно все дополнительные поля объединить в одно и назвать это "маской прав".
1.5.2. Эффективные права
Кроме того, можно вычислить эффективные права и добавить поле в таблицу "пользователь-право". Это потребует обновления этого поля при каждом изменении других таблиц, однако существенно ускорит проверку прав.
Права в программе могут разграничиваться не только по функциям, но и по объектам. К примеру, один и тот же пользователь может иметь право "только чтение" для одной папки и "полный доступ" для другой папки.
В этом случае права должны даваться не вообще, а на конкретные объекты. Однако так как на разные объекты могут даваться одинаковые права, то можно воспользоваться следующей структурой:
Т.е. дополнить таблицу "пользователь - право" колонкой, в которой будет указано, к какому объекту это право дано. Точно так же должны быть расширены таблицы: роль-право, группа-право и группа-роль. Таким образом, разграничивая доступ к объектам, мы добавляем новое измерение к модели.
Если же позволить назначать права не только на объекты, но и на группы объектов (т. к. назначать права на каждый объект в отдельности трудоемко), то получаем шесть сущностей (пользователь, группа, право, роль, объект, группа), которые объединяются восемью тройными связями. Восемью, так как у нас три пары сущностей, а 2^3 = 8. Еще есть три двойные связи (право-роль, пользователь-группа и объект-группа).
Это подводит к мысли - нельзя ли обойтись общей таблицей "право на"?
Объектов, как правило, очень много, существенно больше, чем пользователей и прав. Поэтому объекты не только объединяют в группы, но и организовывают в иерархии (вероятно, появятся системы, в которых группы и роли так же образуют иерархии). Иерархию можно изобразить в виде дерева. При этом права могут назначаться непосредственно листу или узлу, либо могут браться права узла более близкого к корню. Это называется наследованием прав.
В случае наследования прав возникает вопрос - что делать, если установлен флаг "права наследуются" и права определены непосредственно для самого объекта. Одно из решений - объединять такие права (как на допуск, так и на недопуск), другое - не позволять определять права для объекта, если установлен флаг "права наследуются".
В случае если берутся либо права предка, либо права объекта, можно завести у объекта поле - откуда брать права. Это поле является кешем и должно обновляться при изменении поля "права наследуются" у объекта и у его предков.
В данной работе рассмотрены различные схемы хранения информации о правах доступа. Для конкретной системы нужно строить свою схему исходя из требований по быстродействию и уровню ограничения доступа.
