PhpGACL — система управления правами

КИРИЛЛ СУХОВ

PhpGACL – cистема управления правами

Авторизация, аутентификация – эти проблемы всегда появляются при разработке многопользовательских веб-приложений. Для их решения применяются различные механизмы, которые давно и хорошо известны. Задача контроля прав доступа несколько сложнее, а её универсальное решение с произвольным количеством объектов и субъектов, причём с простым управлением вырастает в довольно серьёзную работу. Я не раз и не два наблюдал, как программист создал собственную систему управления правами, да и сам изобрёл пару велосипедов на этом фронте. PhpGACL – это набор функций, призванный если и не решить проблему управления правами раз и навсегда, то по крайней мере, значительно её упростить. Он легко встраивается в готовое приложение и позволяет реализовать довольно сложную схему полномочий пользователей. Объектами доступа могут быть веб-страницы сайта, базы данных, другие пользователи, хосты и т. д. Для установки не требуется ничего, кроме наличия реляционной базы данных (PostgreSQL, MySQL, Oracle, Interbase или библиотеки SQLite) и абстрактный класс доступа к базам данных ADOdb.

Для чего нужна система управления правами?

Как пример приложения возьмём веб-интерфейс к клиентской базе некого телекоммуникационного предприятия. Доступ к нему в той или иной степени имеют все сотрудники, с той разницей, что, если такие атрибуты, как ФИО, контактные телефоны, email, общедоступны (на чтение), то с более конфиденциальной информацией, такой как финансовая история, технические детали, могут быть ознакомлены только те, кто по своим должностным обязанностям имеют на это право. Изменять наиболее важные сведения (состояние лицевого счёта, атрибуты контракта) имеют право лишь несколько сотрудников, несущих ответственность за свои действия. Кроме того, есть ещё индивидуальные роли – секретарь должен иметь доступ к финансовой истории, чтобы отвечать клиентам на претензии, скажем, по поводу приостановки услуги за неуплату, он же должен иметь возможность изменять некоторые атрибуты клиента (состояние услуги, или, скажем, ФИО), системному инженеру должна быть доступна возможность менять сетевые параметры и т. д.

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

Субъекты   Объекты	Просмотр списка клиентов	Просмотр персональной информации	Изменение персональной информации	Просмотр баланса	Изменение баланса
Вася (менеджер)	+	+	–	–	–
Коля (менеджер)	+	+	–	–	–
Света (менеджер по работе с клиентами)	+	+	+	–	–
Оксана (секретарь)	+	+	–	+	–
Саша (администратор)	+	+	+	+	+
Костя (Нач. отдела биллинга)	+	+	+	+	+
Женя (сотрудник отдела биллинга)	+	+	–	+	–
Андрей (зам. начальника отдела биллинга)	+	+	–	+	+

Недостатки тут не очевидны, наоборот, при такой схеме всё кажется явным и прозрачным.

Проблемы начинаются тогда, когда операции с правами пользователей немного выходят за штатный режим. Допустим, менеджер по работе с клиентами увольняется или заболевает, и его функции (если точнее, его права) необходимо срочно передать кому-то другому, в чьи служебные обязанности они ранее не входили. Причём системного администратора, который может назначить эти функции, поковырявшись в базе данных «отвёрткой», в данный момент нет на месте, да и вообще данное ковыряние – по сути, нештатная операция, которая в нормально организованной системе не должна иметь место. Конечно, можно прописать соответствующие права у конкретного объекта доступа, но особенность подобных систем состоит в том, что пользователей (другими словами, субъектов доступа), как правило, гораздо больше, чем объектов. Причём при вышеописанном матричном подходе (в худшем случае, но случае вполне реальном) нам придётся определять права всех пользователей при доступе к каждому конкретному объекту. Конечно, можно ввести права «по умолчанию», но тогда проблемы возникнут при добавлении нового объекта. Ещё одна проблема заключается в том, что при реальной работе (ну, скажем, вышеописанной болезни администратора) бывает так, что права доступа к объектам назначать просто некому. Таким образом, система распределения и управления правами должна включать и возможность некоторым категориям пользователей давать права доступа другим. В этом, кстати, коренное отличие желаемой логики от логики распределения прав, существующих в современных файловых системах, таких, как NTFS или различные файловые системы *nix. Подход, который использует phpgacl, конечно, не панацея, но довольно эффективен. Он заключается в рассмотрении пользовательских прав не со стороны объектов, а со стороны субъектов доступа. Исчерпывающие примеры, демонстрирующие её работу, даны в документации, я же сейчас попробую рассмотреть несколько упрощённую модель.

Для начала определимся с терминами. В любой системе распределения прав существует, по крайней мере, три понятия – это пользователь, запрашивающий доступ, объект, доступ к которому запрашивается, и, собственно, тип доступа (скажем, чтение или изменение данных). В phpgacl пользователю соответствует определение ACO (Access Control Objects – Объекты контроля доступа). В данном случае это просто пользователи системы. Объектам соответствует определение ARO (Access Request Objects – Объекты запроса доступа), которое включает в себя любые объекты доступа, определяемые приложением.

С третьим пунктом (тип доступа) немного сложнее. В базовой модели применения это понятие вообще не предусмотрено, почему – об этом позже. Разумеется, в любой сколько-нибудь сложной системе данная вещь необходима, и в phpgacl она, разумеется, присутствует (AXO – Access eXtension Objects – Объекты расширения доступа), но применение данного средства не всегда нужно, по крайней мере, по двум причинам. Первая и самая очевидная из них – специфика доступа в веб-приложениях. Как правило, на «низком» уровне доступ сводится к предоставлению пользователю прав выполнить определённый скрипт. Вторая причина состоит в том, что результат проверки доступа, который возвращает система, имеет булевой формат (ALLOW или DENY) и соответственно тип доступа (если в таковом есть необходимость), должен быть так же описан как объект.

Логика работы

Сразу хочу предупредить (честно говоря, для меня это было камнем преткновения), что phpgacl не даёт возможности указывать права пользователя на конкретные скрипты, веб-страницы или, скажем, таблицы базы данных. Всё, что она делает, – это управляет логикой распределения прав. Авторизацию, аутентификацию, привязку к объектам должно взять на себя ваше приложение. Чтобы получить представление, как именно это можно сделать, советую посмотреть реализацию административных функций в популярной CMS (Content Manager System) Mambo (http://mamboserver.com), где phpgacl встроена в систему и практически нигде явным образом не видна, но берёт на себя всю работу распределения прав пользователей.

Основное отличие phpgacl от вышеописанного табличного (матричного) подхода в том, что система описывает структуру прав «сверху вниз», исходя из субъектов (каковыми в данном случае являются сотрудники). Субъекты могут быть организованы в группы, причём любого уровня вложенности. Права назначаются субъектам и группам и могут быть переопределены внутри групп. Очень важно понимать, что проверка прав заключается в возвращении булевого значения для любого запроса. Как не совсем очевидное следствие такого подхода – невозможность прямо получить ответ на вопрос вида «кто имеет доступ к изменению баланса клиента?» (в отличие от вопроса «Имеет ли Вася такой доступ?»). Система смотрит на права с точки зрения субъектов, а не объектов доступа.

Инсталляция

Требования довольно гуманны. Необходима версия PHP-интерпретатора не ниже 4.2.0*, любой веб-сервер с поддержкой PHP (настоятельно не рекомендуется только Apache 2.x) и реляционная база данных (декларируется поддержка MySQL, PostgreSQL, Oracle, Sybase, но ничто не мешает использовать MSSQL или вообще любую СУБД, которую поддерживает php-расширение adodb. Мне удалось после небольших изменений работать даже с СУБД cache, но это, разумеется, уже экзотика).

Сначала скачаем архив с библиотекой (http://phpGACL.sourceforge.net) и распакуем его в каталог вашего веб-приложения. Далее открываем и редактируем файл phpgacl/gacl.class.php. В нём надо определить следующие настройки:

var $_db_table_prefix = "galc_";      // префикс для наименования таблиц в базе данных

var $_db_type = "mysql";       // тип базы данных

var $_db_host = "localhost";   // хост базы данных

var $_db_user = "root";        //пользователь базы данных

var $_db_password = ""; //пароль пользователя

var $_db_name = "gacl";        //имя базы данных

var $_db = "";          // объект ADODB database connector (если ADODB не использовалось и не настраивалось, можно оставить пустым)

Теперь нужно отредактировать phpgacl/admin/gacl_ admin.inc.php, продублировав в нём ту же информацию. Этот файл необходим административной части скрипта. Причина, по которой одна и та же информация вводится дважды, проста – gacl.class.php невелик по размеру и большинстве случаев нет необходимости включать в приложение весь программный интерфейс. (Мне это кажется некоторой недоработкой, которая, впрочем, легко исправляется). Создаём базу данных с именем, которое мы задали в db_name и запускаем скрипт http://localhost/phpgacl/setup.php. Он создаст необходимые таблицы в базе данных и в конце работы порадует примерно таким сообщением:

phpGACL Database Setup Configuration: driver = mysql, host = localhost, user = root, database = gacl, table prefix = galc_   Testing database connection... Success! Connected to "mysql" database on "localhost".   Testing database type... Success! Compatible database type "mysql" detected! Making sure database "gacl" exists... Success! Good, database "gacl" already exists! Success! Installation Successful!!! *IMPORTANT* Please make sure you create the /admin/templates_c directory, and give it write permissions for the user your web server runs as. Please read the manual, and docs/examples/* to familiarize yourself with phpGACL. Let"s get started!

Как видно из последнего замечания, следует вручную создать каталог /templates_c в каталоге phpgacl/admin (смысл данного действия, по-видимому, кроется в возможности задать права на запись) и перейти по ссылке «Let’s get started!». После этого программа установки выведет отчёт о состоянии вашей системы и запросит подтверждения. Немножко подумав (для виду), можно согласиться. Если все настройки правильны, вы попадаете в интерфейс администратора системы, где уже можно начинать работу – создавать группы, пользователей, объекты и разделы. В родном интерфейсе phpgacl всё довольно понятно, и я бы не хотел долго объяснять, на какие кнопки нажимать, лучше остановимся на организации прав доступа.

Для начала разобьём весь персонал компании на вложенные группы и определим ARO:

Сотрудники              Группа

├─Менеджеры             Группа

│ ├─Вася                ARO

│ ├─Коля                ARO

│ └─Света               ARO

├─Отдел биллинга        Группа

│ ├─Костя               ARO

│ ├─Женя                ARO

│ └─Андрей              ARO

├─Оксана                ARO

└─Саша                  ARO

Следующим этапом установим права доступа для действий (то есть ACO) для каждой группы или ARO, входящих в получившееся дерево (в данном случае мы исходим из того, что по умолчанию доступ куда бы то ни было запрещён всем).

Сотрудники              [ALLOW: Client_list]

├─Менеджеры             [ALLOW: Show_balance]

│ ├─Вася

│ ├─Коля

│ └─Света               [ALLOW: Change_balance]

├─Отдел биллинга        [ALLOW: ALL]

│ ├─Костя

│ ├─Женя                [DENY: Change_balance] [DENY: Change_person]

│ └─Андрей              [DENY: Change_person]

├─Оксана                [ALLOW: Show_person] [ALLOW: Show_balance]

└─Саша                  [ALLOW: ALL]

Данная схема охватывает все права, но совсем не идеально построена (напоминает сработанную «на коленке»), но это вполне реальный пример, и далее будем отталкиваться от него. Теперь рассмотрим любую типовую ситуацию. Скажем Андрей, неожиданно (или ожидаемо) взял отпуск. Костя в силу своей загруженности не может целиком переложить на себя его обязанности и решает переложить их на Женю. Коля по каким-то причинам утратил доверие, и было принято решение, что он вполне может справляться со своей работой, без информации о финансовом положении клиента. Более того, решено, что Вася теперь будет иметь доступ к счетам клиентов. Действия по изменению логики доступа, несмотря на некоторое несовершенство начальной схемы, минимальны. Типовые действия по изменению, добавлению прав будут показаны ниже, но в данном случае важна получившаяся диаграмма доступа (а если называть вещи своими именами, ACL – Access Control Lists дерево), она будет выглядеть так:

Сотрудники              [ALLOW: Client_list]

├─Менеджеры             [ALLOW: Show_balance]

│ ├─Вася                [ALLOW: Change_balance]

│ ├─Коля                [DENY: Show_balance]

│ └─Света               [ALLOW: Change_balance]

├─Отдел биллинга        [ALLOW: ALL]

│ ├─Костя

│ ├─Женя                [DENY: Change_person]

│ └─Андрей              [DENY: Change_person]

├─Оксана                [ALLOW: Show_person] [ALLOW: Show_balance]

└─Саша                  [ALLOW: ALL]

Сразу скажу, что такой ACL выглядит довольно загруженно (при небольшом числе субъектов), но phpGacl позволяет группировать и комбинировать субъекты, строя сколь угодно сложные схемы. Один и тот же ARO может быть членом разных групп, в частности, если в вышеприведённом примере мы решим дать Васе дополнительные полномочия, можно просто добавить его в группу «отдел биллинга»:

Сотрудники              [ALLOW: Client_list]

├─Менеджеры             [ALLOW: Show_balance]

│ ├─Вася

│ ├─Коля                [DENY: Show_balance]

│ └─Света               [ALLOW: Change_balance]

├─Отдел биллинга        [ALLOW: ALL]

│ ├─Костя

│ ├─Женя                [DENY: Change_person]

│ ├─Андрей              [DENY: Change_person]

│  └─Вася

├─Оксана                [ALLOW: Show_person] [ALLOW: Show_balance]

└─Саша                  [ALLOW: ALL]

Как это реализовать на программном уровне? Прежде всего следует сказать, что phpGACL идентифицирует каждый объект доступа типом объекта (ARO, AXO, ACO) и двумя ключевыми словами – именем раздела и значением. Раздел – это заданная пользователем общая категория объекта доступа, значение – название для объекта доступа.

Добавление нового элемента в схему происходит следующим образом:

Добавление ARO “Раздел -> Значение”:

“Billing_group -> Vasya”

“Managers_group -> Oksana”

В данном случае тип объекта понятен из контекста, и его можно опустить. Таким же образом происходит добавление объектов других типов.

Уровень API

На более низком уровне работа приложения с phpgacl проходит посредством вызова функций программного интерфейса.

Вот пример из руководства, реализующий простую проверку логина и пароля:

// Подключаем базовый API

include("phpgacl/gacl.class.php");

$gacl = new gacl();

$username = $db->quote($_POST["username"]);

$password = $db->quote(md5($_POST["password"]));

$sql = "SELECT name FROM users WHERE name=";

$sql .= $username." AND password=".$password;

$row = $db->GetRow($sql);

if($gacl->acl_check("system","login","user",$row["name"])){

  $_SESSION["username"] = $row["name"];

  return true;

}

else

  return false;

Обратите внимание, что здесь используется только один вызов, а именно функция acl_check(), которая проверяет ARO-объект $row["name"] в ARO-разделе «user» и ACO-объект «login» в ACO-разделе «system». Надо отметить, что функции API не входят в официальную документацию, но их описание доступно в каталоге docs/phpdoc/ дистрибутива.

При написании статьи был использован русский перевод документации phpgacl (http://php.russofile.ru/phpGACL.html), выполненный Кузьмой Феськовым.