Если веб-сайт Вашего клиента обслуживается более чем одним человеком, то Вам следует подумать над предоставлением ACL [cписка контроля доступа], основанного на ролях. Что такое основанный на ролях ACL [список контроля доступа] и почему Вам следует использовать его, вместо подхода к ACL [cпискe контроля доступа, примененного в Joomla] 1.5?

По-честному, Joomla 1.5 обладала одной явной проблемой, которая припятствовала ее пригодности под многие корпоративные проекты. Разработчик веб-сайта [такого проекта] был крайне ограничен в предоставлении разных ролей поддерживающим этот веб-сайт сотрудникам.

Обязанности за разные разделы этого веб-сайта не могли быть изолированы друг от друга. Если пользователю был нужен один функционал или [один] определенный компонент, который требовал, чтобы этот пользователь был [с правом] "администратора", то нам приходилось назначать этого пользователя администратором. Почти неизменно, мы раздавали больше прав и доступа к [куда] большему [числу] районов [веб-сайта], чем это требовалось любому отдельному пользователю. Такое ограничение для большинства компаний неприемлимо.

К счатью, это ограничение было снято в [семье версий Joomla] 2.5. Но вот в чем проблема... многие разработчики веб-сайтов не очень далеко отклоняются от модели ACL [списка контроля доступа, примененного на] 1.5.

Как выглядит основанное на ролях?

Роль имеет тенденцию представлять [собой] некоторое логическое задание или набор обязанностей, которые принадлежат внутри организации или компании. Она назначаема какому-либо индивидуалу и может быть перенесена на других индивидуалов или разделена между ними. Некая "роль" - это некая концепция, которую организация определяет и обыденно понимает.

Например, роль "выполнения заказа" предоставит некоему пользователю способность доступа к заказам, доступа к информации по доставке, [способность] изменять статус заказа и корректировать в инвентаризации число проданных товаров. Но для управления информацией по товарам возможно потребуется другая роль, а для доступа к финансовой информации покупателей или возвращении [покупателям] денег - другая. Один пользователь может быть назначен всем этим ролям, в то время как другой пользователь назначается только одной из них. Полные возможности какого-либо пользователя определяются совокупностью назначенных ему или ей ролей.

Типичные характеристики какой-либо роли

Доступа и прав, ассоциируемых с ролью, в точности хватает для осуществляения какой-либо задачи или набора относящихся к ней задач. Это включает [в действие] принцип "наименьшей привилегии".

Задачи и обязанности одной роли изолированы от задач и обязанностей других ролей (и обычно не накладываются на нее). Это включает [в действие] принцип "разделения обязанностей".

1. Роль является представителем комбинации частей [веб-сайта], доступ к которым придается уровнями прав.
2. Какому-либо человеку может быть назначена одна или несколько ролей.
3. Более чем один человек могут разделять одну и ту же роль.
4. Среди пользователей какая-либо роль может быть легко добавлена, удалена или перенесена.
5. Какая-либо роль соответствует в названии и возможностях деловой концепции этой "роли".

Большинство из этого было невозможно применить в Joomla 1.5. Все из этого может быть [применено] в 2.5. Модель ACL [списка контроля доступа] 2.5 предоставляет нам способность применять все эти характеристики, но она ни требует, ни принуждает нас к этому. Фактически, конфигурация ACL [списка контроля доступа] по умолчанию [версии 2.5] выглядит как [конфигурация] ACL [списка контроля доступа версии] 1.5.

Вид основанного на роли ACL [списка контроля доступа] значительно отличается от ACL [списка контроля доступа] который мы получаем из коробки.

Санда Потье (Sander Potjer), разработчик плагина "ACL Manager", сказал мне, что он предпочитает удалять большинство из групп пользователей [установленных] по умолчанию и перестраивать группы пользователей как нужно для какого-либо данного проекта. Для основанного на роли решения это имеет смысл. До недавнего времени, это могло быть не практично. Слишко много разработчиков расширений потерпели неудачу в предоставлении начальной поддержки ACL [списка контроля доступа] в своих компонентах для версий 1.6/1.7/2.5. В результате мы не могли использовать какую-либо произвольную группу для доступа к этим компонентам, - нам приходилось назначать какого-либо пользователя группе "manager" или даже "administrator". К счастью, текущие версии "ACL Manager" могут автоматически предоставлять начальный ACL [список контроля доступа] компонентам на 2.5, которым его не хватает. В заключении, мы [теперь] можем даже удалять [группы пользователей] "manager" и "administrator". Если Вы будете применять сто процентно подход основанный на ролях, то они бесспорно Вам больше не нужны.

Что мы преобретаем в основанной на роли [модели]?

Основанная на роли модель, [примененная в какой-либо компании] очень близко соответствует деловым правилам [этой] компании. Бизнес лидеры понимают концепцию ролей и исследования нескольких организаций открыли, что они предпочитают определять и контролировать доступ согласно различных назначенных людям ролей. Если мы будет моделировать наш ACL [список контроля доступа] согласно наших деловых правил, то мы будет сдавать нашим клиентам систему управления содержимым, которая подстраивается под нужды их сотрудников и будущие изменения.

Поразмышляйте над реалиями, с которыми сталкиваются компании: сотрудники и обязанности сотрудников со временем изменяются. Люди приходят и уходят и обязанности перемещаются. Роли, возможно, придется быстро назначить, отозвать или изменить. Иногда, какая-либо роль разделяется между несколькими людьми. Часто, какой-либо сотрудник будет удерживать несколько ролей. Роли должны быть назначаемы индивидуально и иногда какая-либо роль может быть назначена или отозвана как неподходящая под должность или класс пользователя. Умная безопасность призывает людей получать доступ только [к тому], что им нужно.

Компании ожидают [как само собой разумеющееся] что они смогут выполнять все это. Если мы подстраиваем ACL [список контроля доступа] чтобы организовать его вокруг основанных на ролях групп, то тогда мы предоставляем нашим клиентам систему управления пользователями и их ролями, которая интуитивна и [которую] легко администрировать.

Назначенные какому-либо пользователю роли влияют на то, к чему этот пользователь имеет доступ в административной панели.

Это изображение иллюстрирует три выгоды основанного на ролях ACL [списка контроля доступом]. Первая: назначение ролей пользователям является интуитивным. Он [ACL] использует терминологию, которая понятна компании. Контроль доступа сегментирован согласно того, как данная организация понимает и определяет роли [своих сотрудников]. Главная роль по управлению пользователяями и назначению пользователям прав должна принадлежать наиболее подходящему человеку - даже если этому человеку не хватает технических знаний этой системы. Эта основанная на ролях система является достаточно интуитивной.

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

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

Другой образ мышления относительно ACL [списке контроля доступа].

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

Эта статья выстраивает аргумент для перемещения на подход, основанный на ролях. Следующая статья будет рассматривать применение и проиллюстрирует рабочий сценарий.

Возможно, не отклоняться от модели [примененной в Joomla 1.5] покажется безопаснее. Но организации, веб-сайты которых обслуживаются многочисленными людьми, ожидают нечто лучшее. Мы можем доставить лучшее. И когда мы приносим Joomla! корпорациям и большим организациям, то нам нужно доставлять лучшее.

Примечание переводчика: в этой первой из двух статей по ACL [списку контроля доступа] Joomla автор Рэнди Кери (Randy Carey) рассмотрел основные концепции и принципы ACL [списка контроля доступа], главным образом с точки зрения удовлетворения им деловых требований бизнеса владельца веб-сайта. В его следующей статье "Применение основанного на ролях ACL [списка контроля доступа]", рассматривается как применить эти принципы ACL [списка контроля доступа] на практике.