В данной статье я расскажу вам о способе организации прав доступа к web-ресурсу на основе ролевой модели.
Сразу замечу, что прикладную реализацию получения или проверки прав на каком-либо из языков программирования приводить здесь не буду, а остановлюсь только на инфологической модели базы данных.
Считаю грамотную организацию хранения такой информации наиболее важной, поскольку гибкая и отвечающая заявленным требованиям модель в дальнейшем позволит расширять систему легко и безболезненно, а также реализовать её без всякого труда на любом из web-ориентированных языков.
Предложенный мной способ похож на такую популярную организацию прав доступа, которая изложена в phpGACL.
Итак, этот способ реализации подойдет вам, если:
1) Вы хотите иметь возможность получать права доступа пользователя для конкретного объекта системы, в том числе, для каждого конкретного пользователя;
2) Вы хотите организовать пользователей таким образом, чтобы каждый из них относился к какому-либо субъекту, внутри которого имел бы определенный набор прав, а также, чтобы пользователь имел возможность относиться сразу к нескольким субъектам;
3) Было бы просто замечательно, чтобы некоторые пользователи внутри субъекта могли бы управлять правами доступа других пользователей внутри этого же субъекта без участия администратора, при этом сами бы такие пользователи не выходили за рамки прав своего субъекта;
4) Вам бы хотелось, чтобы система организации была интуитивно понятна и имела простую организацию на любом из языков программирования, предназначенных для web-разработки, а также, чтобы ее хранение можно было организовать в любой из реляционных баз данных;
5) В дальнейшем перед информационной системой будет стоять задача логирования действий пользователя, и Вы хотели бы иметь непосредственную связь между системой прав доступа и системой логирования.
Перейдем к рассмотрению практического примера:
Стоит задача организовать систему управления проектами, например, таким образом:
Система:
- Администратор;
- Контент-менеджер.
Проект:
- Менеджер проекта;
- Куратор проекта;
- Заказчик проекта;
- Аналитик проекта;
- Исполнитель проекта;
- Тестировщик проекта.
Рассмотрим модель БД, реализующую хранение системы прав:
Что мы имеем:
1) object – объект доступа;
2) action – действие, производимое над object;
3) permission – разрешение на действие action над объектом object;
4) user – пользователь;
5) project – проект (в других ИС может быть «партнер», «контракт» и т.д.);
6) project_type – тип проекта;
7) user_assigment – привязка пользователя user к конкретному проекту project;
8) role – роль для типа проекта project_type;
9) role_permission – назначение разрешения permission роли role;
10) role_user_assigment – назначение привязки пользователь-проект user_assigment конкретной роли;
11) removed_permission_user_asgmt – удаление разрешения permission конкретной привязки user_assigment.
Далее рассмотрим последовательность наших действий:
1) В соответствии с задачей мы имеем 2 типа проекта: пользовательский проект и система, фиксируем их в project_type.
2) Также у нас есть 2 роли для типа «система» и 6 ролей для типа «пользовательский проект», фиксируем их в role под соответствующим project_type.
3) Далее определяем объекты object, с которыми будут работать пользователи. (например, «профиль пользователя», «задача», «тестирование», «заметка» и т.д.)
4) Определяем действия action, производимые для всех object. Это как классические CRUD, так и специфические для системы: «назначить», «заблокировать», «скачать» и т.д.
5) Из определенных действий и объектов формируем коллекцию разрешений permission, например: «Добавить задачу», «Отредактировать заметку» и т.д.
6) Создаем для конкретных ролей role разрешения permission.
7) Далее остается только создать конкретных пользователей и проекты, связать первых со вторыми в user_assigment и назначить им роли в рамках определенного проекта в таблице role_user_assigment.
В данной системе нет такого понятия как запрет, поэтому если у пользователя есть 2 роли, то его правами доступа будет считаться объединение всех разрешений для этих ролей.
При этом, если необходимы чтобы у пользователя не было какого-то конкретного разрешения из его прав, достаточно просто внести это в таблицу removed_permission_user_asgmt (что будет означать отсутствие таких прав доступа). Например, для тестировщика необходимо выдать разрешение, которое есть только у роли «Менеджер проекта». В таком случае достаточно тестировщику назначить роль «Менеджер проекта» и в removed_permission_user_asgmt внести все разрешения, кроме необходимого.
В рамках этой организации не возникает никаких трудностей, чтобы дать право какой-либо из ролей пользовательского проекта самостоятельно назначать роли пользователям внутри проекта, при этом он не сможет назначить себе или кому-то еще разрешения роли «администратор системы», потому что для выбора ему будет предоставлены только те роли и разрешения, которые связаны с его project_type.
Замечу, что подобная организация отлично взаимодействуют с системой логирования (в данной статье она не приведена, ввиду её простоты), поскольку мы можем узнать, какое действие произвёл конкретный пользователь в определенный момент.
Также подобная система организации прав отлично сочетается с системами уведомлений и системами потока задач.
Система уже 2 года используется в одной из информационных систем для бизнеса (реализация приложения на php, база данных oracle), куда отлично вписывается.
Автор: Iamarsey
