Ролевая модель и авторизация

Доступ в Диспетчере НТБот выдаётся набором прав. Право — это отдельное разрешение на чтение или изменение одного типа данных: сценариев, хранилища, тестов, генераторов, SLA, проектов, лицензий, журнала аудита.

Права хранятся в Keycloak как клиентские роли клиента ntdispatcher и передаются приложению в токене доступа. Механизм аутентификации и авторизации реализован на Keycloak — см. Управление доступом.

Роли

Чтобы не выдавать права поштучно, в Keycloak заведены три роли, собранные из атомарных прав. Пользователю назначается роль, а вместе с ней — все входящие в неё права.

Роль	Назначение	Входящие права
«Администратор» (Admin)	Администратор платформы	`access`, `project.read`, `project.manage`, `scenario.read`, `scenario.edit`, `scenario.manage`, `storage.read`, `storage.edit`, `test.read`, `test.manage`, `sla.read`, `sla.edit`, `generator.read`, `generator.manage`, `license.read`, `license.manage`, `user.manage`
«Пользователь» (User)	Инженер по нагрузочному тестированию	`access`, `project.read`, `scenario.read`, `scenario.edit`, `scenario.manage`, `storage.read`, `storage.edit`, `test.read`, `test.manage`, `sla.read`, `sla.edit`, `generator.read`, `generator.manage`, `license.read`
«Администратор ИБ» (Auditor)	Контроль событий безопасности	`access`, `auditlog.read`

В Keycloak Admin Console роли отображаются латинскими именами Admin, User и Auditor.

Роль «Пользователь» отличается от «Администратора» отсутствием прав project.manage, license.manage и user.manage. Право auditlog.read не входит ни в «Администратора», ни в «Пользователя» — журнал аудита читает только «Администратор ИБ».

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

Права доступа

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

Права на изменение включают соответствующее право на просмотр: выдав scenario.edit, отдельно выдавать scenario.read не нужно. Так же связаны generator.manage → generator.read, license.manage → license.read, project.manage → project.read, scenario.manage → scenario.read, sla.edit → sla.read, storage.edit → storage.read, test.manage → test.read.

Право	Что открывает
`access`	Вход в Диспетчер. Проверяется на каждом запросе
`project.read`	Просмотр списка проектов и выбор текущего проекта
`project.manage`	Раздел «Проекты» в меню пользователя: создание, изменение и удаление проектов
`scenario.read`	Раздел «Сценарии» и открытие сценария на просмотр
`scenario.edit`	Создание, изменение и удаление сценариев; работа с артефактами, переменными, тестовыми данными, расписанием; сохранение и импорт
`scenario.manage`	Кнопки «Запустить» и «Валидировать» на странице сценария
`storage.read`	Раздел «Хранилище» и выбор артефактов из хранилища в сценарий
`storage.edit`	Импорт, обновление и удаление артефактов в хранилище
`test.read`	Разделы «Тесты», «Сравнить тесты», карточка теста и результаты
`test.manage`	Остановка и пауза теста, изменение числа потоков, изменение описания теста, обучение модели ИИ-анализатора
`sla.read`	Раздел «SLA»: просмотр наборов, транзакций и целевых значений
`sla.edit`	Создание, изменение, копирование и удаление наборов SLA
`generator.read`	Разделы «Генераторы» и «Эмуляторы», карточки эмулятора и адреса
`generator.manage`	Добавление, изменение и удаление генераторов, эмуляторов и их адресов
`license.read`	Раздел «Лицензии»
`license.manage`	Загрузка, запрос и удаление лицензии
`auditlog.read`	Раздел «Журнал аудита»
`user.manage`	Управление пользователями. Разделов в интерфейсе Диспетчера не открывает — пользователи заводятся в Keycloak Admin Console

Поведение при нехватке прав

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

Если права на просмотр есть, а на изменение нет, раздел открывается только для чтения: кнопки создания, изменения и удаления и пункты меню действий неактивны.

Назначение прав в Keycloak

Права и роли создаются автоматически при установке и обновлении платформы — отдельной настройки не требуется.

Назначение роли пользователю выполняется в Keycloak Admin Console:

Открыть realm ntdispatcher.
Перейти в раздел Users и выбрать пользователя.
Открыть вкладку Role mapping.
Назначить клиентскую роль клиента ntdispatcher: Admin, User или Auditor.

Вместо роли пользователю можно назначить отдельные права из таблицы выше — например, только access, test.read и storage.read для наблюдателя. Право access в таком наборе обязательно.

При установке с нуля платформа создаёт двух пользователей: dispatcheradmin с ролью «Администратор» и dispatcheruser с ролью «Пользователь». Пароли этих учётных записей необходимо сменить после первого входа — см. Настройки безопасности.

Роли ADMIN и USER предыдущих версий

До перехода на права доступа в платформе использовались две роли — ADMIN и USER. Они признаны устаревшими и заменены ролями «Администратор» (Admin) и «Пользователь» (User).

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

При обновлении платформа сама доназначает новые роли: пользователи с ролью ADMIN дополнительно получают «Администратора», с ролью USER — «Пользователя». Устаревшие роли при этом не снимаются и не удаляются — снять их нужно вручную в Keycloak Admin Console после проверки.

Устаревшая роль SECURITY_SUPERVISOR по-прежнему открывает раздел «Журнал аудита», но на роль «Администратор ИБ» (Auditor) при обновлении не переносится: пользователям с этой ролью нужно назначить Auditor вручную.

Внешние скрипты и интеграции, опирающиеся на ROLE_ADMIN и ROLE_USER, требуется перевести на права доступа.

Первый вход

При первом входе в систему требуется создать проект — без выбранного проекта разделы «Сценарии», «Тесты», «SLA» и «ИИ анализатор» работать не будут. Создание проекта доступно по праву project.manage.