LDAP. Как обеспечить доступ на редактирование дашбордов

У пользователей LDAP: доступ к дашбордам есть, но не ясно как управлять типом доступа (чтение, редактирование,…).
Например, не ясно как получить доступ к self-services (нет кнопки в UI). Пользователь с признаком “админ”, так же не может редактировать дашборды.
Видимо через LDAP доступ только на просмотр.

Добрый день!

Только у пользователя с ролью “admin” присутствует возможность редактировать дэшборды.
Пользователи с ролью “usual” имеют доступ только к просмотру.

Для назначения роли “админ” при работе с LDAP необходимо изменить строку в таблице “rbac.domain_group_admin_maps” с указанием группы и домена пользователей, которым необходимо предоставить роль “admin”.
Пример:
update rbac.domain_group_admin_maps set user_group=‘AD-AUTH3’;

Для добавления в таблицу “rbac.domain_group_admin_maps” дополнительных пользователей со статусом admin, необходимо добавить строку со столбцами “user_domain”, “user_group” и “access_level”.
Пример:
INSERT INTO rbac.domain_group_admin_maps (user_domain, user_group, access_level, config, updated, created) VALUES(‘DOMAIN1’, ‘AD-AUTH3’, ‘admin’, ‘{}’::jsonb, statement_timestamp(), statement_timestamp());

Скажите пожалуйста, а adm.users править не надо.
Там access_level сам установится нужный?

При работе по LDAP в adm.users править access_level не требуется, так как поступившая информация для проверки пользователя через AD перезапишет указанную вами информацию.
Необходимо настраивать роль “admin” только в таблице rbac.domain_group_admin_maps.

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

И конечно, нужно планировать доработку, чтобы редактировать дашборды могли не только админы.

Спасибо.
В настоящее время мы работаем над улучшением функционала.

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

получается хитрее. датасеты видны все, а дашборды, только что включены в RBAC

При работе с включенным RBAC роль “admin” из группы rbac.domain_group_admin_maps является приоритетнее выставленных прав в разделе rbac.
Подскажите, находится ли в данной таблице пользователь, на которого действуют права(rbac) из вашего вопроса ?

Да. пользователь из этой группы админов.

Как я и писал ранее, на пользователя с ролью “админ” не влияют ограничения со стороны rbac.
Для того чтобы Админу выставить абсолютные права необходимо в таблице rbac.rules добавить строку с группой и доменом админа, например, командой:
INSERT INTO rbac.rules (user_domain, user_group) VALUES(‘GROUPS’, ‘DOMAIN’);

Если подытожить:

Для добавления роли “админ” пользователю в рамках “группы” и “домена” при работе с LDAP:

  1. – добавить внешнюю группу для админов:
    INSERT INTO rbac.ext_groups (group_name) VALUES (‘VIRTUAL_ADMINS’);

  2. – добавить внешний домен для админов:
    INSERT INTO rbac.ext_domains (domain_name) VALUES (‘<AD_DOMAIN>’);

  3. – добавить админские права группе в домене:
    INSERT INTO rbac.domain_group_admin_maps (user_domain, user_group, access_level) VALUES (‘<AD_DOMAIN>’, ‘VIRTUAL_ADMINS’, ‘admin’);

  4. – добавить правила, которые будут применяться к админам:
    INSERT INTO rbac.rules (user_domain, user_group) VALUES (‘<AD_DOMAIN>’, ‘VIRTUAL_ADMINS’);