Аналитические статьи

Преимущество ролевого ACL

Joomla
Добавление в избранное
Сохранить

Преимущество ролевого ACL

Преимущество ролевого ACL - группы в Joomla 1.5Объективно, у Joomla 1.5 была одна явная проблема, которая мешала полноценно использовать ее во многих корпоративных проектах. У разработчика сайта были строгие ограничения в предоставлении прав тем, кто следил за сайтом.

Обязанности различных частей сайта нельзя было отделить друг от друга. Если пользователю была нужна возможность или особый компонент, требующий прав администратора, нужно было сделать этого пользователя администратором. Преимущество ролевого ACL - группы в Joomla 2.5Таким образом, мы предоставляем право доступа также и в другие части сайта, куда доступ ему не требуется. Такая ситуация неприемлема для многих организаций. К счастью, эту проблему устранили в версии 2.5. Но проблема заключается в том, что многие разработчики сайтов не хотят отходить от ACL версии 1.5.

Как выглядит ролевой 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 - роли и доступ к модулям

На скриншоте показаны три основных плюса ролевой ACL.

Во-первых, назначение ролей пользователям легко и понятно. Используется терминология, применимая в бизнесе. Контроль доступа разделен по принципу, с помощью которого организация разделяет роли и обязанности. Роль управления пользователями и назначениями прав должна принадлежать наиболее подходящей кандидатуре, даже, если он или она не разбираются в технической стороне вопроса. Все работает на уровне интуиции.

Во-вторых, роли могут накапливаться у определенного пользователя. Это отражает реальную обстановку в компаниях.

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

Другой взгляд на ACL

В этой статье представлен альтернативный взгляд на управление правами доступа. Это не новый метод. Ролевой контроль доступа ("Role-Based Access Control" (RBAC)) был описан в 1996 году и широко используется в бизнесе и информационных системах. Вообще-то, новая структура ACL Joomla соответствует модели, известной как RBAC. Она работает, если настроить группы пользователей и их роли вместо использования типов пользователей (очень важно различие). Таким образом, Joomla дает фундамент для построения серьезной системы, основанной на принципе предоставления ролевого права доступа. В уроке "Внедрение ролевого ACL в Joomla" мы рассмотрим внедрение этого метода и посмотрим, как он работает.

Может показаться, что уходить от модели версии 1.5 не безопасно, но в организациях, где много работников управляет сайтами нужно нечто большее. И это большее может дать нам Joomla.

Оформление и редакция статьи: Dmitry Rekun

Оригинальная статья: Randy Carey
Katerina Vorobyova
Переводчик, IT любитель, фотомодель.

Подпишитесь на рассылку новостей CMScafe