Редактор политик

Доступ пользователей к Webim реализован при помощи подхода Attribute-based access control (ABAC), базируемом на атрибутах действий, объектов и т.п. Разграничение прав доступа в Webim происходит на основе вычисления политик и правил с определённым набором условий для проверки атрибутов. Таким образом, доступы пользователя не привязаны просто к одной из существующих в системе ролей, а могут настраиваться гибко.

Ниже описаны примеры работы с политиками в Редакторе политик. Теоретические основы работы с политиками описаны в соответствующих статьях (Базовые понятия, Выражения).

Подробности создания, редактирования и удаления ролей описаны в этой статье.

Внимание!

Работа с ролями доступна только для клиентов, подключивших соответствующую тарифную опцию.

Создание политик для роли

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

При помощи контекстного меню можно также поменять положение группы политик относительно других групп – поднять выше или опустить ниже, отключить или удалить группу политик или политику.

Добавление группы политик для роли

Для примера добавим для роли Кастомная роль с идентификатором customrole группу политик. Через контекстное меню группы политик Разрешения сотрудников по ролям добавляем вложенную группу политик. Заполняем поля, как показано ниже, и нажимаем Сохранить.

Через контекстное меню можно поднять группу политик так, чтобы новая группа политик была выше по отношению к группе политик Оператор.

N.B.

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

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

N.B.

Все новые элементы создаются по умолчанию неактивными. Это значит, что они не участвуют в принятии решений о доступе.

Настройка доступа к списку сотрудников

В группу политик Кастомная роль добавляем политику Сотрудники. Для удобства можем считать, что это нечто наподобие папки, в которой будут содержаться все связанные с действиями над сотрудниками правила доступа. Дополнительные фильтры в назначении в данном случае не требуются.

Для доступа к некой сущности в системе предполагается наличие прав:

На доступ к UI и необходимым для его работы API
На непосредственное действие над сущностью: чтение, редактирование и т. п.

Для начала добавим доступ к UI и API. Это можно рассматривать как доступ к самому списку. Для этого в политику Сотрудники добавим новое правило Доступ к списку.

Добавление нового правила Доступ к списку

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

Добавление нового правила Чтение данных о сотрудниках

Настройка доступа к профилю

У сотрудника с ролью Кастомная роль может быть необходимость обновить свой пароль. Для этого требуются разрешения:

Доступ к API списка сотрудников и к UI профиля
Чтение и обновление данных о себе

N.B.

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

Добавим политику Профиль для связанных с профилем правил доступа.

Добавление политики Профиль

Добавим правило на доступ к API сотрудников и UI профиля.

Добавление правила в политику Профиль

И разрешение на чтение и обновление данных о себе. В данном случае, кроме обычных условий вроде субъект = сотрудник необходимо дополнительное условие субъект = объект, которое делает правило применимым только в случае, когда сотрудник выполняет действие над самим собой.

Добавление разрешения на чтение и обновление данных о себе

Настройка доступа к чату

Для чата требуются следующие разрешения:

Доступ к UI РМО
Видимость секций (вроде Ожидают ответа, В диалоге с Вами и т.п.)

Создадим политику Чат.

Создадим правило, разрешающее доступ к UI РМО.

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

Ожидают ответа (queue)
В диалоге с Вами (in_chat)
Офлайн-обращения (offline_queue)
Последние диалоги (closed_chats)
В диалоге с другими (in_chat_with_others)

Теперь, после включения созданной политики и правил, у сотрудника с ролью Кастомная роль появляется возможность общения с посетителями.