Разграничение прав доступа

Пользователи, группы, права

Права доступа к биллингу распределяются по пользователям. Пользователи также могут принадлежать одной или нескольким группам, у которых также настраиваются права на выполнение тех или иных действий. Настройка пользователей, групп и принадлежности пользователей группам выполняется в меню Сервис ⇒ Администрирование ⇒ Пользователи и права.

Первым шагом является заведение группы действий. Для этого перейдите на вкладку Группы и нажмите Добавить на стандартной панели инструментов.

Дважды кликните по узлу Все действия для его раскрытия. После этого проставьте галочки на всех разрешённых группе действий. Далее выберите группы договоров, с которыми сможет работать данная группа, используя разрешённые ей действия. (Например, есть две группы, у одной разрешены действия с DialUp и группа договоров DLP, у другой разрешены действия с Email, и группа договоров EML, если назначить эти группы пользователю, то он не сможет работать с договорами EML используя действия DialUp)

В каждой группе помимо действий могут быть установлены фильтры по группам договоров и Запрещённые параметры - параметры договоров, которые данная группа изменять не может. Настройка действий, групп договоров и запрещенных параметров также может быть индивидуальной для каждого пользователя (см. далее).

При проверке каждого действия, сервер проверяет все группы, в которые входит пользователь (включая индивидуальные права) и ищет разрешение данного действия. Если действие в некоторой группе разрешено, то оцениваются фильтры по группе договоров и запрещённым параметрам (если это необходимо). В случае удовлетворения фильтров всем условиям действие разрешено. В противном случае - запрещено.

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

То же относится и к группам договоров - разрешён будет максимум из присвоенных клиенту групп пользователей. Если в какой-нибудь из групп пользователей не будет фильтра по группам договоров (и будет установлен параметр ИЛИ, см.далее) - будет разрешена работа со всеми договорами.

Если в группе пользователей или у пользователя не будет фильтра по группам договоров (не будет отмечено ни одной группы), то в этом случае поведение системы будет зависить от параметра И/ИЛИ:

При установленном параметре ИЛИ будет разрешена работа со всеми договорами;
При параметре И будет разрешена работа только с договорами, не входящими ни в одну группу.

Таким образом, если необходимо не учитывать разрешения группы или пользователя к группам договоров, то уберите все галочки и установите параметр И. А при включенном параметре*ИЛИ, будет разрешено все, вне зависимости от других групп пользователей или пользователя.

На вкладке Пользователи заводятся пользователи системы, там же определяется принадлежность пользователя группам. Индивидуальные разрешения на действия, фильтры запрещённых параметров и групп договоров можно рассматривать, как уже упоминалось ранее, как добавление ещё одной группы.

Указание групп договоров непосредственно в пользователе скрывает неуказанные типы договоров при поиске. Режим совпадения и/или для Групп договоров означает, что пользователь видит договор либо при наличии всех определённых для него групп в договоре, либо хотя бы одной из определённых для него групп.

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

В общем случае следует сначала сопоставить пользователю группы действий, пароль и прочие опции, исключая Действия. После этого сохранить пользователя. Если требуется добавление персональных действий, не включённых в указанные группы, открыть редактор пользователя снова и проставить на вкладке Действия требуемые разрешения. Выделенные серым блокированные галочки уже указаны в группах пользователя.

Поле Привязка к договору в свойствах пользователя позволяет заводить в системе агентов. При этом все агентские договоры должны иметь параметр типа Ссылка на договор (Агент в примере) и значение этого параметра должно быть равным агентскому договору (NK00001-03 для приведённого выше снимка экрана). Данному пользователю системы будет разрешена работа только со своими договорами. Они же будут выведены в результатах поиска. В договоре агента (NK00001-03 в примере) вы можете вести взаимозачёты с агентом. Правка параметра Агент должна быть запрещена для пользователя-агента!

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

user.actions.permit.show_errors=0 - сокрытие ошибок Доступ запрещён от пользователя, при этом сервер просто игнорирует запрещённые действия.

Включить/выключить проверку прав можно в конфигурации сервера. Права пользователя, чей код в базе равен 1, не проверяются, он может делать все. По умолчанию это admin, созданный установочным скриптом.

В дополнение к системе разграничения доступа система предоставляет возможность аудита действий пользователей. Журнал запросов доступен в меню Сервис⇒Журналы⇒Журнал запросов.

При просмотре списка пользователей возможна фильтрация по имени пользователя и статусу.

Настройка дерева действий

Права на выполнение различных действий внутри системы контролируются подсистемой BGSecure. Все действия в биллинге собраны в древовидную структуру. При установке модуля вместе с ним инсталлируются его действия. Действия модуля прописаны в файле, расположенном в каталоге BillingServer/actions.

При необходимости вы можете корректировать файл, добавляя свои собственные действия. Например, можно определить редактирование каждого параметра договора отдельным действием, либо просмотр каждого отчёта. Т.к. действия просматриваются по порядку, то свои действия необходимо добавлять перед существующими

Запросы вы можете посмотреть в файле log, запустив клиент биллинга в DEBUG-режиме скриптом abilling_debug.bat (.sh), либо воспользуйтесь Сервис⇒Журналы⇒Журнал запросов. О различиях в видах запросов к серверу вы можете посмотреть здесь.

Файлы с конфигурациями действий перетираются при каждой установке/обновлении модуля, не забывайте заново корректировать их, если вы добавили в них собственные действия. Вы также можете создать orig-файлы конфигурации действий, что позволит корректировать файлы только, если они действительно изменились в дистрибутиве. Нумеруйте свои действия номерами больше 1000, чтобы не наступил конфликт ваших действий с добавляемыми стандартными.

HTTP Action

Действия определяются в следующем виде:

<group title="Модули и услуги">
 <action id="14" mask="module=service;action=GetServices" title="Просмотр услуг"/>
 <action id="15" mask="module=service;action=UpdateService" title="Обновление услуги"/>
 <action id="16" mask="module=service;action=DeleteService" title="Удаление услуги"/>
</group>

Группы предназначены исключительно для их визуального разделения в графическом дереве. Каждое действие должно иметь уникальный в пределах файла код id. Маска mask действия определяет набор параметров HTTP-запроса, по которым он будет отнесён к данному действию. В параметре запроса может быть указано и REGEXP-выражение, это позволяет выделять некоторые типы действий. Например, в модуле dialup можно выделить в отдельное действие переобсчёт сессий по конкретному договору:

"module=dialup;action=RecalculateSessions;contract=R:\d+"

Как видно из примера, REGEXP указывается после строки R:.

Web-сервис

Действия определяются в следующем виде:

<group title="Платежи">
   <service id="89" name="PaymentService" operation="paymentList" title="Просмотр платежей"/>
   <service id="90" name="PaymentService" operation="paymentUpdate" title="Изменение платежа" expression="payment.getId() gt 0"/>
   <service id="101" name="PaymentService" operation="paymentUpdate" title="Добавление платежа"/>
</group>

Первичным ключом действия выступает имя Web-сервиса и операция. С помощью JEXL выражения в expression возможно дополнительная фильтрация параметров метода (см. пример). Все параметры метода передаются в JEXL контекст и у них могут быть вызваны функции. В приведённым выше примере по признаку неположительного идентификатора платежа отделены добавление и изменение платежа.

Доступность пунктов меню в клиенте BillingClient

Для каждого пользователя, либо для группы пользователей, ко всему прочему, можно настроить также и возможность скрытия ненужных по каким-либо причинам пунктов меню в клиенте BillingClient. Само описание меню хранится в файле BillingServer/data/menu.xml в виде дерева. Например:

...
<menu title="Сервис" id="service">
    <menu title="Журналы" id="log">
        <menuItem id="query" className="avantis.abilling.module.admin.bgsecure.ActionQueryLogViewer" title="Журнал запросов"/>
        ...
    </menu>
</menu>
...

Каждый элемент меню однозначно характеризуется связкой <код меню>.<код пункта меню>. При наличии вложенности нескольких меню для определения конкретного пункта меню (т.е. листа дерева), используется только последний код меню, непосредственно включающего данный пункт. Например, пункту меню Сервис ⇒ Журналы ⇒ Журнал запросов соответствует ключ log.query (см. код выше). Пункты меню, соответствующие конкретному модулю имеют код вида <код модуля>. Например, для модуля Inet c кодом 12 код пункта меню будет равен 12. Пункты меню, соответствующие плагинам, прописаны в файле plugin.xml, который находится в корне jar-архива плагина. Данный архив находится в папке <Billing_server_path>/lib/app.

Для того, чтобы скрыть от пользователей или их групп часть меню или элементов меню, необходимо при редактировании конкретного пользователя или конкретной группы перейти на вкладку Пункты меню. Для добавления, удаления или редактирования правила на скрытие (или, напротив, отображения) какого-либо пункта меню или целого меню необходимо нажать на соответсвующие кнопки над таблицей с правилами.

Для добавления нового правила необходимо ввести код меню (или пункта меню), которого оно касается, а также указать показывается он или является скрытым. Для скрытия целого меню используется правило вида <код меню>, а для скрытия конкретного подпункта - <код меню>.<код пункта меню>.

Важно заметить, что правила для конкретного пользователя имеют более высокий приоритет, чем групповые. Например, для группы "Операторы" можно скрыть все меню Модули, но для оператора Васи сделано исключение, и оно будет отображаться.

При наличии же нескольких групп у пользователя сложение правил видимости действует по принципу "сложения по видимости". Т.е. если некий пользователь Петров принадлежит к двум группам (группе А и группе Б), причем в группе А действует правило невидимости пункта меню Модули, а у группы Б - пункта меню Плагины, то у Петрова все равно будут видны оба этих пункта. Потому что ни у одной из этих двух групп нет общих правил невидимости пунктов меню. Если же Петров будет принадлежать либо к группе А, либо группе Б (но не одновременно к обоим), то у него не будет виден пункт либо, соответственно, Модули, либо - Плагины.

Скрытие пунктов меню для пользователей не относится к системе BGSecure и носит чисто визуальный характер! При использовании альтернативных клиентов права действия "внутри" пунктов меню необходимо разграничивать при помощи системы BGSecure.