Тестируем Insight и видим, что по конструктору есть потребность в организации Object Level Security на следующих принципах:
Добавить возможность централизованно администратором включить обязательную аутентификацию по всем или по определённым проектам.
Добавить возможность ограничивать права на просмотр или редактирование к определённым проектам в ролях Keycloak или внутренних ролях системы.
Текущий принцип, что редактор сам волен включать аутентификацию не годится для организации self-service.
Предполагаемый сценарий работы:
IT создаются проекты в редакторе Insight и datasources в Dremio.
В Keycloak создаются роли.
IT настраивает security для datasources в Dremio и доступ на чтение/запись для определённых ролей в проектах.
Бизнес заказывают роли для редактора Insight, заходят только в доступные им проекты и самостоятельно строят дашборды на основе доступных им источников dremio.
Привет, немного общей информации, если появятся вопросы далее, то продолжим
Начнем с того, что в системе есть editor (где работают разработчики приложений) и player (здесь обычные пользователи). Принципы настройки управления полномочиями отличаются.
Editor
Подключение аутоинтефикации через keycloak настраивает devops при установке Insight (сотрудник, который разворачивает и настраивает конфигурацию платформы).
По умолчанию каждый разработчик имеет свою область, и не видит проекты других. Но имеет возможность адресно обмениваться доступом к приложению с другими разработчиками.
Player
Для настройки аутоинтефикации требуется настройка keycloak. Инструкция предоставляется по запросу. Это выполняет, как правило, администратор платформы.
Ведение пользователей, ролей и другой атрибутики может выполняться в keycloak. Как правило, выполняет администратор, отвечающий за ведение пользователей и ролевой модели.
Для того, чтобы аутоинтефикация работала в приложении нужно обязательно настроить сервис, а также добавить в шаблон или на страницу «Авторизационный контейнер». Только в этом случае пользователю будет предложено окно keycloak с предложение ввести пару логин и пароль или будет обеспечено SSO. Настройку выполняет разработчик приложения.
Для того, чтобы сделать разграничение доступа к контенту приложения, используется виджет «Разграничение контента»: Инструкция тут и Видео
Ограничение по данным:
Основную роль тут играет dremio connector, который выполняет функцию ограничения поступающих от клиента запросов данных с учетом конфигурации разграничения полномочий. На данный момент это управляется через 3 таблицы. В 1 кв 2023 будет специализированный UI. На данный момент настройкой разграничения доступа к данным занимается разработчик приложения через UI Dremio.
Андрей, спасибо, я так понял это в следующей версии редактора (у нас сейчас такой возможности нет)? И можно будет именно в ролях разграничить доступ к проектам? Т.к. шаринг пользователей проектов друг между другом плохо поддаётся контролю, удобнее делать это ролями и раздавать централизованно.
Привет, кратко расскажу, как будет работать функциональность после выхода ближайшего релиза.
В Keycloak администратор создает группы на специальной закладке (см. скриншот). Группа может быть равна роли. Например, мы (Goodt) используем группы на нашем партнерском тенанте, чтобы разделять доступы между партнерами.
Администратор прикрепляет пользователя к группе или к нескольким группам.
Первый и второй шаг можно загрузить из внешней системы, если такие данные имеются, чтобы не вносить вручную.
Далее пользователи работают в своих проектах. Если есть необходимость поделиться, то пользователь нажимает галочку поделиться в Группе, и тогда проект становится доступен участникам всех групп, в которых состоит пользователь.
Следующими релизами мы планируем развивать эту историю, обеспечивая новые возможности для настройки бизнес-правил доступа к проектам.
