Права доступа в AW BI: два уровня, атрибуты и RLS
О чём эта статья. Разбираем, как устроена система прав доступа в AW BI — от базовых прав на объекты до построчной фильтрации данных (RLS). Это первая часть из двух. Во второй части — практический кейс с виджет-навигатором.
Два уровня прав доступа
Когда говорят о правах доступа в AW BI, часто имеют в виду сразу две разные вещи. Их легко перепутать, поэтому важно разделить с самого начала.
Первый уровень — кто вообще может зайти и что видит в интерфейсе. Это классические права: кому открыт просмотр модели, дашборда, виджета. Настраиваются через кнопку «Общий доступ» на каждом объекте. Работает как пропуск в здание — либо есть, либо нет.
Второй уровень — что пользователь видит внутри данных. Два человека зашли в один и тот же отчёт, но один видит данные по Москве, другой — по Екатеринбургу. Это называется Row Level Security (RLS). Такое название, потому что доступ к данным реализован построчно. Как если бы в одном здании у всех были разные окна с разными видами.
В обоих статьях мы работаем именно со вторым уровнем.
Важно: в AW BI ограничения RLS применяются только при просмотре виджетов и дашбордов. В разделе «Модели» вы всегда видите все строки — это сделано намеренно для удобства администрирования. Не пугайтесь, если при проверке в модели видите все данные — проверять нужно через виджет.
Атрибуты, схема доступов, провайдер
Что такое атрибут
Атрибут — это характеристика пользователя, которая хранится в системе рядом с его логином. Например:
login= ivanovdepartment= hrregion= msk
Когда система решает, какие строки данных показать пользователю, она берёт его атрибуты и сравнивает с полями в модели. Совпадение нашлось — строка видна. Нет — скрыта.
Аналогия: атрибут — это штамп в пропуске сотрудника. «Допущен к складу №3, город Казань». Система смотрит на штамп и решает, что показывать.
Что такое схема доступов
Прежде чем использовать атрибут в правиле фильтрации, его нужно «объявить» в системе. Схема доступов — это реестр всех атрибутов, которые система умеет использовать для RLS.
Встроенные атрибуты (всегда присутствуют): login, email, state, user_roles.
Кастомные атрибуты добавляете вы сами — department, region и всё что нужно для вашей логики.
На картинке выше как раз отображается интерфейс создания нового атрибута в системе, той самой нужной нам “печати”. Стоит тут отметить, что это возможно сделать пользователям с уровнем администратора.
Что такое модель user_permissions
Это специальная встроенная модель AW BI — таблица пользователей с их атрибутами. По умолчанию она пустая. Администратор, а точнее технический администратор системы, наполняет её данными — загружает из базы данных или Excel-файла.
Минимальная структура: поле login (логины, совпадающие с учётными записями в системе) плюс любые кастомные атрибуты, которые вам нужны.
После загрузки значения из этой таблицы становятся атрибутами каждого пользователя.
Что такое провайдер
Провайдер — источник, откуда система получает данные о пользователях при входе. Есть два варианта:
- Внутренний провайдер AW — данные берутся из модели
user_permissions. Всё управляется внутри AW BI вручную или через файл. - Внешний провайдер (LDAP, OpenID, Keycloak и др.) — атрибуты приходят автоматически из корпоративной системы аутентификации.
Маппинг схемы — вкладка в настройках провайдера, где вы связываете поля из источника с атрибутами схемы доступов. Нужна, потому что имена полей в источнике и в схеме могут не совпадать.
Как работает RLS
Вот полная цепочка от входа пользователя до отображения данных в виджете:
| Шаг | Что происходит |
|---|---|
| 1 | Пользователь входит в систему |
| 2 | Провайдер возвращает его атрибуты (из user_permissions или внешней системы) |
| 3 | Атрибуты маппятся на схему доступов |
| 4 | При открытии виджета система проверяет правила доступа модели |
| 5 | Строки фильтруются: пользователь видит только «своё» |
Что будет, если user_permissions заполнена не полностью:
| Ситуация | Результат |
|---|---|
| Модель заполнена полностью | Всё работает как настроено |
| Модель пустая | Все пользователи видят пустой результат |
| Пользователь есть в таблице | Видит данные согласно правилу |
| Пользователя нет в таблице | Видит пустой результат — атрибут не найден |
| Правило доступа не создано | Все видят все строки без ограничений |
user_permissions— он зайдёт в систему и увидит пустой виджет. Не ошибку, не «доступ запрещён» — просто пустоту. Это частая причина обращений к администратору после онбординга нового сотрудника.
Продолжение — во второй части. Там мы разберём практический кейс: настроим виджет-навигатор, который у каждого пользователя показывает только те дашборды, к которым у него есть доступ.