Объективно, раньше была одна явная проблема, которая мешала полноценно использовать ее во многих корпоративных проектах. У разработчика сайта были строгие ограничения в предоставлении прав тем, кто следил за сайтом.
Как выглядит ролевой ACL?
Например, роль "заказчика" дает пользователю доступ к заказам, информации по доставке, смене статуса заказа, а также к изменению количества товара, который выставлен на продажу. Еще одна роль может потребоваться для управления информацией о продукте, также доступу к финансовой информации о клиенте или возврату товара. Можно назначить для одного пользователя все эти роли, а для другого – всего лишь одну из них. Полный список возможностей пользователя зависит от всех назначенных для него ролей.
Типичные свойства роли
Права доступа, прикрепленные к роли дают возможность для выполнения задания или набора родственных заданий. Здесь начинает действовать принцип «наименьшего уровня привилегии».
Задания и обязанности, привязанные к роли не связаны (и обычно не совпадают) с обязанностями и заданиями других ролей. Работает принцип «разделения обязанностей».
- Роль – это набор зон, ограниченных правами доступа.
- Пользователю можно назначить более одной роли.
- Одна роль может быть распределена между несколькими пользователями
- Роль можно добавлять, удалять или передавать другим пользователям.
- Роль соответствует понятию и возможностям делового концепта «роль».
- Почти все это невозможно настроить в Joomla 1.5 и возможно в 2.5. Модель ACL 2.5 дает возможность применить все эти свойства, но не требует от нас этого. По факту, настройка ACL по умолчанию выглядит также как ACL в 1.5 во многом его эмулируя.
Ролевой ACL значительно отличается от ACL, который мы получаем "из коробки". Сандер Потьер, разработчик ACL Manager, рассказал, что предпочитает отключать большинство стандартных пользовательских групп и переделывать этот набор под нужды своего проекта. Это логично для ролевой системы, но до недавних пор это было не практично. Лишь у немногих разработчиков получалось обеспечить базовой поддержкой ACL для компонентов версий 1.6/1.7/2.5. В результате, нельзя было назначать собственным группам доступ к этим компонентам, и нужно было делать пользователя менеджером или даже администратором. Если вы на 100% внедрите ролевой метод вам, возможно, не понадобится это делать.
Чем подкупает ролевой метод?
Ролевой подход вполне соответствует деловым правилам организации. Бизнес-лидеры понимают, в чем заключается понятие роли, и изучение политики некоторых организаций открывает тайну о том, как они предпочитают распределять и управлять обязанностями, назначая каждому свою роль. Если настроить ACL в соответствии с бизнес-правилами, то в итоге клиент может получить CMS, отвечающую потребностям работников компании с учетом будущих изменений.
Вот реалии бизнес-среды: с течением времени работники и их обязанности меняются. Люди приходят и уходят, а их обязанности передаются. Роль нужно будет назначать, удалять или быстро изменять. Иногда одна роль дается нескольким пользователям. Часто работникам даются несколько ролей. Должна быть возможность назначить роль индивидуально, а иногда, роль удаляется или назначается по признаку "должности" или класса пользователей. Из соображений безопасности, лучше назначать только те права доступа, которые требуются.
В бизнесе все это важно. Если настроить ACL в ролевых группах, клиент получит систему управления пользователями и их ролями, которые легко освоить и настроить.
На скриншоте показаны три основных плюса ролевой ACL.
Во-первых, назначение ролей пользователям легко и понятно. Используется терминология, применимая в бизнесе. Контроль доступа разделен по принципу, с помощью которого организация разделяет роли и обязанности. Роль управления пользователями и назначениями прав должна принадлежать наиболее подходящей кандидатуре, даже, если он или она не разбираются в технической стороне вопроса. Все работает на уровне интуиции.
Во-вторых, роли могут накапливаться у определенного пользователя. Это отражает реальную обстановку в компаниях.
В-третьих, у каждого пользователя CMS будет доступ только к тем частям сайта, которыми он должен управлять в соответствии со своими обязанностями. Если установить ролевые права доступа соответствующим ролевым группам, можно осуществить следующее: пользователь видит панель администратора, настроенную в соответствии с его ролями.
Другой взгляд на ACL
В этой статье представлен альтернативный взгляд на управление правами доступа. Это не новый метод. Ролевой контроль доступа ("Role-Based Access Control" (RBAC)) был описан в 1996 году и широко используется в бизнесе и информационных системах. Вообще-то, новая структура ACL Joomla соответствует модели, известной как RBAC. Она работает, если настроить группы пользователей и их роли вместо использования типов пользователей (очень важно различие). Таким образом, Joomla дает фундамент для построения серьезной системы, основанной на принципе предоставления ролевого права доступа. В уроке "Внедрение ролевого ACL в Joomla" мы рассмотрим внедрение этого метода и посмотрим, как он работает.
Может показаться, что уходить от модели старой версии не безопасно, но в организациях, где много работников управляет сайтами нужно нечто большее. И это большее может дать нам "новая" Joomla.