11 Администрирование
Для того, чтобы перейти в раздел “Администрирование”, кликните на его обложку на стартовой странице либо выберите этот раздел в панели навигации.
Раздел “Администрирование” доступен только пользователям с лицензионной ролью Admin.
Функционал раздела “Администрирование” в Luxms BI позволяет:
- Создавать и редактировать учётные записи пользователей, в том числе назначать права доступа к определённым атласам и/или кубам.
- Синхронизировать группы пользователей Luxms BI и группы AD.
- Создавать и редактировать парольные политики.
- Вносить изменения в конфигурацию системы.
Перед тем, как начать знакомство с текущим разделом, нужно познакомиться с ролями пользователей в Luxms BI.
Роли пользователей в Luxms BI
Роли описывают преднастроенные права пользователей, но только в части запрета тех или иных действий. В Luxms BI предусмотрено два типа ролей: лицензионная и сайтовая.
При создании пользователя ему обязательно присваивается сайтовая роль, которая привязана к одной из лицензионных ролей.
Лицензионные роли
Лицензионные роли описывают ограничения, которые нельзя отменить никакими настройками в Luxms BI. Эти ограничения не подлежат изменению или отмене. Единственный способ изменить эти ограничения – обратиться к производителю Luxms BI.
В поставку Luxms BI входят три лицензионные роли: Viewer, Creator, Admin.
1) Viewer. Лицензионная роль Viewer запрещает создавать, изменять и редактировать объекты в Luxms BI. Это роль только для просмотра готовых приложений (атласов).
2) Creator. Лицензионная роль Creator запрещает выдавать права на объекты и управлять пользователями и группами пользователей, но позволяет разрабатывать приложения в Luxms BI, подключать источники данных, запускать ETL задачи.
3) Admin. Лицензионная роль Admin не накладывает никаких ограничений на действия в Luxms BI. Эта роль имеет полный доступ ко всем действиям и объектам.
Сайтовые роли
Сайтовые роли являются производными от лицензионных ролей и добавляют дополнительные ограничения к базовой лицензионной роли, которые нельзя отменить путём настройки прав доступа другими механизмами Luxms BI.
Перечень и права сайтовых ролей можно настроить под свои нужды, но при этом нельзя снять ограничения, которые наложены исходной лицензионной ролью.
Не рекомендуется менять перечень сайтовых ролей или менять ограничения сайтовых ролей, установленные производителем. Для изменения сайтовых ролей в системе Luxms BI, где уже зарегистрированы пользователи, требуется консультация производителя или поставщика Luxms BI.
1) Viewer. Сайтовая роль Viewer основана на лицензионной роли Viewer и не имеет дополнительных ограничений относительно неё.
2) Developer. Сайтовая роль Developer основана на лицензионной роли Creator и не имеет дополнительных ограничений относительно неё. Роль предназначена для разработчиков приложений Luxms BI, включая разработку компонентов на JavaScript.
3) Designer. Сайтовая роль Designer основана на лицензионной роли Creator, но ограничивает доступ к функционалу ETL (Luxms Data Boring). Также запрещён функционал редактирования/создания источников данных и кубов. Роль предназначена для создания и редактирования дэшбордов.
4) Self-Service. Сайтовая роль Self-Service основана на лицензионной роли Creator, но ограничивает доступ к функционалу ETL (Luxms Data Boring). Также запрещён функционал редактирования/создания глобальных источников данных и глобальных кубов. Роль предназначена для разработчиков приложений Luxms BI, без возможности создания компонентов на Javascript.
5) Data-Engineer. Сайтовая роль Data-Engineer основана на лицензионной роли Creator, но ограничивает доступ к функционалу создания дэшбордов. Роль предназначена для разработчиков ETL процессов и редактирования глобальных источников данных и глобальных кубов.
6) Infosec. Сайтовая роль Infosec основана на лицензионной роли Admin, но ограничивает доступ к редактированию объектов в Luxms BI. Роль предназначена для просмотра как атласов, так и административной информации Luxms BI.
7) Publisher. Сайтовая роль Publisher основана на лицензионной роли Admin, но ограничивает доступ к редактированию объектов в Luxms BI и управлению правами. Роль предназначена для обработки запросов на публикацию атласов.
8) Admin. Сайтовая роль Admin основана на лицензионной роли Admin и не имеет дополнительных ограничений относительно неё.
9) Super. Сайтовая роль Super основана на лицензионной роли Admin и не имеет дополнительных ограничений относительно неё. Более того, невозможно установить дополнительные ограничения для пользователя с ролью Super.
Пользователи и группы
На данном экране в Luxms BI можно создавать и редактировать учётные записи пользователей, назначать им права доступа, создавать и редактировать группы пользователей.
Создание нового пользователя
Чтобы создать нового пользователя, нажмите кнопку в окне “Пользователи”.
В появившемся окне необходимо ввести имя, логин нового пользователя в системе и email. Чтобы выбрать сайтовую роль пользователя, откройте выпадающий список и кликните по нужному пункту.
Пароль нужно ввести дважды, чтобы избежать ошибки. Если два пароля не совпадут, оба поля будут выделены красным цветом.
Когда оба пароля совпадают, поля для их ввода подчёркиваются зелёным и кнопка “Создать пользователя” в правом нижнем углу окна становится активной. Кликните по ней, и новый пользователь появится в общем списке.
При создании нового пользователя проверяется уникальность email. Если email, который вы хотите дать новому пользователю, уже есть в базе данных (у другого пользователя), учётную запись создать не получится.
Над списком пользователей есть поле поиска, чтобы найти конкретного пользователя. Также можно фильтровать список по сайтовым ролям, отметив чекбоксы с нужными ролями в выпадающем списке “Роль”. На рисунке ниже список пользователей отфильтрован по роли Viewer.
Редактирование учётной записи
Чтобы редактировать данные пользователя, удалить учётную запись или назначить права доступа, выберите нужного пользователя в списке. Откроется окно настройки учётной записи.
Общие настройки
Чтобы изменить основные настройки пользователя, кликните на кнопку “Редактировать”. В открывшемся окне вы сможете поменять:
- ФИО (имя)
- Логин
- Телефон
- Сайтовую роль
- Лицензионную роль
- Парольную политику
- Дату смены пароля
При смене сайтовой роли пользователя лицензионная роли меняется автоматически на соответствующую.
Также можно заблокировать учетную запись (9), передвинув одноимённый бегунок. Заблокированный пользователь не сможет залогиниться в системе.
Для удаления пользователя кликните на кнопку “Удалить пользователя” (10). Если вы не хотите потерять правки после выхода из окна настройки пользователя нажмите на кнопку “Сохранить изменения” (11).
Добавление пользователя к группе
Чтобы добавить пользователя к группе, нужно перейти во вкладку “Группы” и кликнуть по кнопке “Редактировать”.
В открывшемся окне кликните по плюсу рядом с заголовком Списка групп пользователя.
В открывшееся окно перетащите (drag’n’drop) плашки с нужной группой.
Удаление пользователя из группы происходит в том же поле.
Для того, чтобы подтвердить изменения, кликните по кнопке “Сохранить изменения”.
Права доступа пользователя
Во вкладке “Права доступа” можно назначить права пользователя на все или отдельные атласы, кубы и источники данных.
Пользователь не может менять собственные парольную политику и сайтовую роль
Красными прямоугольниками отмечены права, запрещённые для сайтовой роли пользователя, зелёными - разрешённые поля, а серыми - те права, которые по умолчанию выключены, но могут быть предоставлены.
Чтобы быстрее найти нужный объект, воспользуйтесь выпадающим списком “Тип объекта”. Он позволяет сузить поиск до групп атласов, глобальных источников и глобальных кубов или даже до отдельных объектов.
Чтобы найти конкретный объект откройте список “Выбор объекта” и найдите его там вручную или с помощью поиска.
Чтобы настроить права доступа, нажмите кнопку “Редактировать” и откройте окно редактирования прав доступа пользователя.
В этом окне находится таблица из объектов и всех прав доступа. Бледно-красный прямоугольник на пересечении строк обозначает действие, запрещённое пользователю его сайтовой ролью. Если на пересечении строк и столбиков расположен белый прямоугольник, значит, администратор может предоставить пользователю право на определённое действие с определённым объектом. Набор доступных действий для атласов, источников и кубов отличаются.
Каждый объект (таблица или запись в таблице) имеет список допустимых действий, которые пользователь потенциально может производить с объектом.
Код | Заголовок | Описание |
---|---|---|
C | Create | Создание |
R | Read | Чтение |
U | Update | Изменение |
D | Delete | Удаление |
S | Share | Поделиться |
Сln | Clone | Копирование объект к себе |
L | List | Возможность выводить список объектов |
M | Move | Перемещение объекта |
O | Open | Открытие объекта (заход внутрь) |
Use | Run/Use | Запуск и использование |
G | Grant | Выдача прав доступа |
P | Publish | Публикация |
RP | Request Publish | Запрос на публикацию |
Exp | Export | Экспорт |
Imp | Import | Импорт |
Полный список действий с объектами в Luxms BI
Права доступа можно задать на:
- абсолютно все доступные права для группы объектов (1) или конкретного объекта (2). Для этого кликтите на прямоугольник на пересечении столбца “all rigts” и строки нужной группы или объекта;
- часть доступных прав на целую группу (3) или конкретный объект (4);
Можно настроить права на:
1) Все атласы. 2) Отдельный атлас. 3) Все дэшборды атласа. 4) Отдельный дэшборд атласа. 5) Отдельный дэш 6) Все источники атласа. 7) Все кубы атласа. 8) Все глобальные источники. 9) Все глобальные кубы.
Для того чтобы ограничить доступ пользователя к просмотру или выгрузке отдельного дэша необходимо кликнуть по шестеренке рядом с названием дэшборда. А в открывшемся окне кликнуть по кнопке (чтобы забрать право на просмотр) или по кнопке (чтобы забрать право на выгрузку). Для того, чтобы вернуть право, достаточно повторного клика.
По такому же принципу можно запретить пользователю все или часть действий на все или часть объектов. Запрещённые действия отмечаются ярко-красными прямоугольниками с белыми крестиками внутри.
Пользователю возможно предоставить только те права, которые разрешены его сайтовой ролью. Чтобы выдать пользователю все права на определённый объект, кликните по белому прямоугольнику на пересечении строки объекта и столбца “all rights”. Если вы хотите выдать права только на некоторые действия, кликните по белому прямоугольнику на пересечении строки объекта и столбца с нужным правом доступа. Чтобы запретить пользователю действие, повторно кликните по зелёному прямоугольнику.
Права на объекты ограничены сайтовой ролью пользователя. Например, невозможно дать пользователю “Viewer” право на публикацию или использование объектов.
Создание новой группы пользователей
Чтобы создать новую группу пользователей, нажмите кнопку в окне “Группы”.
В появившемся окне необходимо ввести название новой группы и нажать кнопку “Создать группу”.
Новая группа появится в списке групп и найти её можно будет вручную или с помощью поиска.
Редактирование группы
Чтобы редактировать группу пользователей, удалить её или назначить права доступа, выберите нужную группу пользователей в списке. Откроется окно группы. Для начала настройки кликните по кнопке “Редактировать”.
Основные настройки
Во вкладке “Основные настройки” можно изменить название группы, а также добавить в неё пользователей.
Любого пользователя можно добавить в любую группу. Чтобы добавить пользователя, кликните по кнопке “плюс” рядом с кнопкой “Список пользователей группы”.
Добавление происходит путем перетаскивания плашки пользователя (drag’n’drop) в открывшееся поле.
После добавления пользователя в поле “Участники” будут видны его имя, логин и сайтовая роль. В этом же поле можно удалить пользователя из группы.
После добавления всех необходимых пользователей в группу нажмите кнопку “Сохранить изменения”.
Права доступа группы пользователей
Настройка прав доступа для группы происходит аналогично настройке прав доступа для пользователя. Чтобы начать настройку, нажмите кнопку “Редактировать”.
Можно настроить права на:
1) Все атласы. 2) Отдельный атлас. 3) Все дэшборды атласа. 4) Отдельный дэшборд атласа. 5) Отдельный дэш 6) Все источники атласа. 7) Все кубы атласа. 8) Все глобальные источники. 9) Все глобальные кубы.
Права пользователя являются более приоритетными, чем права группы. Например, если разрешить пользователю просмотр определённого атласа, а его группе не разрешать, то пользователь всё равно сможет просматривать этот атлас.
Ограничение доступа к данным на уровне записей Row-level security (RLS)
Для групп пользователей возможна настройка Row Level Security на кубы. То есть для группы пользователей можно сделать настройки фильтрации по строкам куба. Например, пользователи в филиале одного города будут видеть данные только по тому городу, в котором находятся.
Чтобы настроить RLS, выберите группу пользователей из списка, кликните на неё и перейдите во кладку “Права доступа”, а потом нажмите кнопку “Редактировать”.
Настройка работает только для кубов, поэтому открываем список глобальных кубов. У интересующего нас куба кликаем по изображению воронки. Дальше можно использовать два механизма настроек прав доступа.
Первый способ позволяет выбрать условие с помощью управляющего дэша. Для этого в окне установки правил, во вкладке RLS, необходимо отметить соответствующие целям фильтрации пункты.
Если выбран только один пункт из списка, то напротив него появится кнопка “Кроме”. При клике по ней будут выбраны все остальные пункты, а тот, что был выбран изначально, пропадет из выборки. Аналогично работают и кнопки “Только” на невыбранных пунктах.
Второй способ настройки фильтрации - ввод формулы в одноименной вкладке. Формула задает условие для фильтрации куба, которое будет применяться, когда кто-то из участников выбранной группы захочет открыть этот куб. Фильтр подтверждаем с помощью кнопки “Применить”.
Для того, чтобы после закрытия окна настройки не потерялись, нажмите кнопку “Сохраните изменения”.
При настройке фильтрации кубов для группы пользователей вы можете использовать стандартные LPE функции и операторы, например, =
, !=
, or
, and
и так далее. Названия операторов or
, and
и др. нужно писать в нижнем регистре.
Если пользователь находится в разных группах и в каждой из групп имеются фильтры RLS для одного и того же куба, то условия фильтров RLS для разных групп будут объединены оператором or
.
Например, в группе MSK для куба cube1 может быть указан фильтр RLS:
column_city = 'Москва' and cust_type = 95
а в группе SPB для этого же куба cube1 может быть такой фильтр RLS:
column_city = 'Санкт-Петербург'
Если пользователь состоит в обеих группах MSK и SPB, то для куба cube1 будет использоваться фильтрация:
WHERE (фильтры из упр. дэша) AND ((column_city = 'Москва' AND cust_type = 95) OR column_city = 'Санкт-Петербург')
Формат правил Row-level security (RLS)
Интерфейс для указания фильтров RLS похож на стандартный управляющий дэш Luxms BI. Формат хранения для этих фильтров поддерживается с версии luxmsbi-pg 9.3.2 и его можно использовать, внося JSON в поле ввода вручную. Формат JSON такой же, как и в теле API вызова /api/v3/koob/data
.
Фильтры в формате JSON сначала группируются по имени столбца и условия для одного и того же столбца объединяются с помощью or
. Для разных столбцов условия фильтров объединяются через and
Если при вычислении RLS фильтров для пользователя придётся сочетать JSON фильтры и обычные текстовые фильтры, то система выдаст ошибку Incompatible filter formats for cube ....
.
Например, в группе MSK для куба cube1 может быть указан фильтр RLS:
{
"column_city": ["=", "Москва"],
"cust_type": ["=", 95]
}
а в группе SPB для этого же куба cube1 может быть такой фильтр RLS:
{"column_city": ["=", "Санкт-Петербург"]}
Если пользователь состоит в обеих группах MSK и SPB, то для куба cube1 будет использоваться фильтрация:
WHERE (фильтры из упр. дэша) AND ((column_city='Москва' OR column_city='Санкт-Петербург') AND cust_type=95)
Так как формат JSON для задания RLS является экспериментальным, существуют ограничения и неудобства при его использовании:
- При смене формата с обычного на JSON будет выводится ошибка. Сначала необходимо полностью удалить условие, сохранить пустое условие, и только после этого вносить условие в формате JSON;
- Нельзя использовать JSON условия RLS и обычные условия в разных группах, если есть пользователи входящие в такие группы одновременно. Требуется сначала очистить фильтры в таких группах, а уже после этого вносить новые фильтры в одинаковом формате.
Синхронизация групп
На данном экране можно настроить синхронизацию АД-групп с ролями и группами в Luxms BI.
Настройка AD описана в “Руководстве Системного администратора”.
Чтобы добавить АД-домен, нажмите кнопку и выберите нужный домен из списка.
АД-группа добавляется аналогично.
Чтобы синхронизировать АД-группы компании-пользователя с ролью в системе, выберите нужную группу и назначьте ей сайтовую роль в окне “Синхронизация доменных групп с системой BI”. В этом же окне можно назначить АД-группе необходимую группу в Luxms BI.
После во вкладке “Результаты” можно увидеть список подключенных АД-доменов, АД-групп и соответствующие им роли и группы в Luxms BI.
Сайтовые роли, которые назначаются на экране “Синхронизация групп”, являются более приоритетными, чем роли, назначаемые индивидуально при редактировании пользователя.
При авторизации пользователя через механизм SSO в Luxms BI автоматически регистрируется новый пользователь, которому назначается Сайтовая роль и он попадает в группы указанные для комбинации AD домена и AD группы пользователя.
Если требуется заранее завести пользователя в Luxms BI, а после его авториации через SSO не переназначать Сайтовую роль и группы, то есть возможность отключить это поведение. Для этого необходимо создать специальную группу пользователей в Luxms BI и вновь созданных пользователей добавлять в эту группу. ident данной группы небходимо указать в Конфигурации системы в настройке userProvision.skipProvisionForUsersInGroup
ident группы можно узнать наведя указатель мыши на значок с буквой (i) в правом верхнем углу окна детальной информации о пользователе:
Разграничение доступа на основе атрибутов (Attribute-Based Access Control, ABAC)
При необхоимости, в Luxms BI имеется возможность поменять атрибутный набор полей, получаемых из IAM системы (Keyсloak, Blitz и пр.). Для этого в таблице adm.scripts необходимо помнять поле script для записи, у которой scope = ‘jwt_user_mapping’. Например, для того, чтобы сохранить все поля из JWT, который приходит из IAM системы в script, внутрь функции begin(…) необходимо добавить строку:
cp(["jwt", "payload"], ["db", "adm","users","sys_config","JWT"]),
После этого, каждый раз при аутентификации пользователя его данные из IAM системы будут сохраняться в таблицу adm.users ы поле sys_config
Чтобы использовать эти атрибуты для задания условий фильтрации при ограничении прав доступа к записям в кубе (см. RLS выше) можно воспользоваться функцией get_in()
Парольная политика
Парольная политика - это набор правил составления паролей, направленных на повышение безопасности программы. Каждая политика определяет допустимую длину пароля и набор символов в нём.
На данном экране можно настроить парольные политики в Luxms BI.
Чтобы добавить новую парольную политику, нажмите кнопку . Откроется окно создания парольной политики.
При создании новой парольной политики можно настроить следующие параметры:
- Название политики. (обязательное поле);
- Длина пароля (минимальное количество символов);
- Заглавные буквы (минимальное количество);
- Цифры (минимальное количество);
- Специальные символы (минимальное количество);
- Уникальные символы (минимальное количество);
- Смена пароля через (количество дней);
- Не использовать предыдущие х паролей.
После ввода информации нажмите кнопку “Сохранить”.
Нажмите кнопку , чтобы редактировать парольную политику. Откроется окно, аналогичное окну создания новой политики.
Для удаления парольной политики нажмите и подтвердите своё действие во всплывающем окне.
Конфигурация системы
На данном экране можно настроить конфигурацию Luxms BI.
Таблица с конфигурацией системы состоит из следующих полей:
- Ключ элемента;
- Настройка активна;
- Значение элемента;
- Описание элемента.
Неактивные настройки отображаются серым цветом. Кликните на чекбокс “Активна” в соответствующей строке, чтобы активировать настройку.
Также над таблицей и под заголовком есть поиск.
Экран “Конфигурация системы” является отображением таблицы adm.configs из БД на веб-клиенте. Не рекомендуется без необходимости менять настройки по умолчанию.
Ниже описаны некоторые параметры с данного экрана:
HTTP.headers.luxmsbi.version
– включает/отключает выдачу версии в заголовке ответа.audit.tracking.topic
– включает/выключает запись событий по действиям пользователей в журнал ИБ (см. раздел “Информационная безопасность”).authorization.mode
– режим авторизации. Если указан rbac, то используются специльные алгоритмы по проверке домена и групп LDAP и правила из таблиц в схеме rbac. Если указан rbac9, то используется новая гранулярная система прав доступа, появившаяся в версии Luxms BI v9.HTTP.default_lang
– Задаёт локализацию для сообщений об ошибках в HTTP API.email.program
– программа, с помощью которой будет отправляться почта.luxmsbi.presentations.mono
- позволяет активировать и деактивировать режим монопрезентации.
Аудит событий безопасности - пятая вкладка в разделе “Администрирование”. Кликнув на эту вкладку вы попадёте в атлас “Аудит событий безопасности”. Подробнее о нём рассказано в разделе “Информационная безопасность”.
API токены
Интерфейс Luxms BI позволяет создавать API токены. Отдельный подраздел для этого создан в разделе “Администрирование”.
Экран API токенов содержит таблицу со списком всех созданных токенов и информацией о них в следующих столбцах:
1) Название 2) Описание 3) Дата создания 4) Кто создал. Здесь возможно три варианта: имя пользователя, система Luxms BI, система Data Boring. 5) Методы. В этой ячейке содержится информация о количестве методов и URL, доступ к которым дает токен. 6) Кому выдан 7) Статус: “Активен” или “Приостановлен”. 8) Переход к кнопкам действий с токеном.
Найти нужный токен в списке можно с помощью Поиска. Для этого достаточно ввести часть названия токена в поисковую строку.
Создание API токенов
Перейти к созданию нового токена можно, кликнув по кнопке .
Откроется окно создания нового токена.
Для того, чтобы создать токен необходимо:
1) Ввести название и описание токена. Если название нового токена совпадёт с названием уже существующего, токен все равно сохранится, поскольку у них будут разные ID.
2) Выбрать пользователя, который получит доступ к токену. Имя можно ввести вручную или найти в поиске.
Важно, чтобы права доступа пользователя не запрещали действия, которые позволяет выполнить токен. То есть, если у пользователя нет прав создавать новые дэшборды, то токен с таким запросом работать не будет.
3) Чтобы указать один или несколько методов и шаблонов URL для этого токена, нужно кликнуть по кнопке . В открывшемся окне нужно отметить чекбокс рядом с пунктом. Сузить список поиска можно, указав в поиске нужный метод или URL.
4) Чтобы выйти из поля выбора методов, достаточно кликнуть по любому участку за пределами поля.
5) Удалить лишний метод можно, кликнув по иконке корзины для бумаг справа от его названия.
Отметим, после выбора методов и URL уже можно создать токен. Соответствующая кнопка “Создать токен” в верхнем правом углу окна становится активной.
6) Однако, если необходимо сделать условия допуска более жесткими, можно прописать дополнительный скрипт в одноимённом окне.
7) Проверить корректность скрипта можно, загрузив входные данные в одноимённое окно (1), прописав условие (2) и нажав кнопку “Выполнить” (3). После выполнения появится результат: True или False (4). Прописать входные данные можно вручную, а можно загрузить с помощью меню “Шаблон”. Опции появляются в тот момент, когда к токену добавляется новый метод или URL.
Проверить корректность токена перед созданием очень важно, поскольку после создания токена отредактировать его уже невозможно.
8) Для завершения нажмите кнопку “Создать токен”.
Новый токен появится в общей таблице.
Действия с API токенами
Со всеми API токенами доступен ряд действий. Для того, чтобы перейти к меню кликните по кнопке
1) Подробнее. Открывает окно просмотра токена. Важно, что редактировать здесь ничего нельзя. В то же время в окне возможно удалить токен, приостановить его действие или копировать токен.
2) Копировать. Позволяет скопировать строку с API токеном. После клика по кнопке текст токена сохраняется в буфер обмена. А в углу экрана появится надпись.
3) Приостановить. После этого действие токена будет приостановлено. После этого кнопка “Приостановить” меняется на “Возобновить”.
4) Удалить. Удаляет токен.
Настройка двухфакторной аутентификации (2fa)
Создать или обновить параметры двухфакторной аутентификации можно с помощью конфигурационной таблицы. В ней должны быть указаны настройки:
cfg_key | cfg_val | is_enabled |
---|---|---|
authentication.mode | 2fa | 1 |
factor2.auth.timeout | 600 | 1 |
factor2.sms.program | /path/to/script.sh | 1 |
При наличии установленного параметра factor2.sms.program
поведение Web-интерфейса меняется и после ввода правильного логина и пароля, пользователь увидит окно для ввода второго фактора. Второй фактор будет сгенерирован сервером и отправлен пользователю путём запуска скрипта указанного в параметре factor2.sms.program
.
Скрипт получает на вход два аргумента:
- Телефон пользователя, который был установлен при создании пользователя. Его можно посмотреть в списке пользователей Luxms BI.
- Второй фактор: код.
Пример запуска:
> /path/to/script.sh '+799999999999' '0123'
При успешной отправке второго фактора скрипт должен вернуть UNIX статус 0 (успех). Другими словами, должен быть сделан вызов exit(0)
. При любой ошибке должен возвращаться ненулевой статус.
Скрипт должен быть доступен пользователю postgres
на чтение.
Пользователь postgres
должен иметь права на выполнение скрипта.
В случае кластерной инсталляции, скрипт должен быть установлен одинаковым образом на всех узлах PostgreSQL (на мастере и всех репликах).
В кластерном режиме скрипт будет запускаться только на мастере PostgreSQL. При отказе мастера, одна из реплик автоматически переключится в режим мастера. Если на реплике не установлен скрипт, то двухфакторная аутентификация перестанет работать.
Параметр factor2.auth.timeout
задаёт время жизни выданного пользователю второго фактора в секундах. В случае, если пользователь введёт второй фактор по истечению указанного срока, система не примет второй фактор и запретит вход. В этом случае, пользователь должен повторить вход в систему сначала, либо запросить новый второй фактор.