Описание личного кабинета

Общее описание

Личный кабинет администратора MULTIFACTOR необходим для того, чтобы управлять вашими ресурсами, пользователями и их группами.

Это краткое руководство поможет вам разобраться в функционале и раскроет все возможности управления сервисом многофакторной аутентификации.

Вход

Вы можете зарегистрироваться, нажав на соответствующую гиперссылку

Вход доступен по логину\паролю, а также через mail.ru почту. В случае утери пароля вы можете восстановить его самостоятельно в окне входа. В случае невозможности подтверждения 2FA, например замена телефона, обратитесь к другому администратору. Ему нужно будет удалить администратора с потерянным методом подтверждения и отправить ссылку на регистрацию по новой. Если вы являетесь единственным администратором, напишите на почту support@multifactor.ru с уточнением, что вы единственный администратор и просьбой сбросить метод подтверждения 2FA.

LDAP аутентификация

Помимо стандартного входа по логину и паролю, Вы можете использовать LDAP-аутентификацию. LDAP-аутентификация позволяет администраторам входить в Личный кабинет с использованием учётных записей Active Directory, Samba AD или другого LDAP-каталога.

Для работы LDAP-аутентификации необходимо:

• настроить LDAP-коннектор;
• выполнить синхронизацию пользователей из LDAP-каталога;
• включить LDAP-аутентификацию для проекта.

После настройки на странице авторизации появится вкладка LDAP.

Как работает LDAP-аутентификация

После ввода пользователем учётных данных на вкладке LDAP платформа Multifactor выполняет следующие действия:

1. Получает имя пользователя и пароль, указанные на странице входа.
2. Определяет пользователя и проект (ЛК), к которому пользователь относится.
3. Проверяет, включена ли LDAP-аутентификация для данного проекта.
4. Загружает параметры LDAP Connector и проверяет доступность.
5. Передаёт запрос на проверку учётных данных в LDAP Connector.
6. LDAP Connector выполняет аутентификацию пользователя в LDAP-каталоге.
7. При успешной аутентификации Multifactor создаёт сессию пользователя и выполняет переход к настройке или подтверждению многофакторной аутентификации.
8. После успешного прохождения многофакторной аутентификации пользователь получает доступ к Личному кабинету.

Если LDAP-аутентификация отключена для проекта, пользователю будет отображено сообщение: LDAP authentication is not enabled

В этом случае необходимо проверить настройки LDAP-аутентификации проекта.

Включение LDAP-аутентификации в личном кабинете

Включите LDAP-аутентификацию в разделе настройки Личного кабинета Multifactor.
После этого нам будут доступны:

• API Key — ключ доступа к API Multifactor, используемый для аутентификации LDAP Connector.
• API Secret — секретный ключ доступа к API Multifactor. Значение хранится в зашифрованном виде.
• URL LDAP Connector — адрес Вашего LDAP Connector.

Скопируйте два параметра: API Key и API Secret, они потребуются для последующих шагов.

Развертывание LDAP Connector

LDAP Connector представляет собой отдельный сервис, который обеспечивает взаимодействие между LDAP-каталогом и платформой Multifactor (MGM).

Важно

Для каждого проекта (Личного Кабинета) рекомендуется использовать отдельный экземпляр LDAP Connector.

Чтобы собрать Docker-образ для LDAP-коннектора, выполните следующую команду в папке с Dockerfile:

docker build -t mf-ldap-connector .

docker run -d \
  -p 8080:8080 \
  -e ADMIN__DEFAULTPASSWORD=MySecurePassword123 \
  -e ENCRYPTION__KEY=<base64-256bit-key> \
  -e LITEDB__PATH=/data/storage.db \
  -v ldap-connector-data:/data \
  mf-ldap-connector

openssl rand -base64 32

Важно

Если LDAP-сервер использует самоподписанный сертификат (или внутренний CA), его нужно добавить в доверенные корневые сертификаты контейнера.

docker cp ldap-ca.crt mycontainer:/usr/local/share/ca-certificates/
docker exec -it mycontainer update-ca-certificates

Настройка LDAP Connector

После запуска LDAP Connector откройте в браузере адрес формата  http://<host>:<port>.

Для входа используйте пароль, указанный в переменной окружения ADMIN__DEFAULTPASSWORD. После первого входа потребуется задать новый пароль администратора.

Откройте раздел Настройки LDAP, где необходимо указать параметры подключения к LDAP-каталогу.

После заполнения параметров нажмите Проверить подключение.

Если подключение выполнено успешно, нажмите Сохранить.

Настройки синхронизации

Откройте раздел Настройки синхронизации. Здесь задаются параметры подключения к MGM API и расписание синхронизации.

После сохранения настроек синхронизация запускается автоматически.

Статус синхронизации

Откройте раздел Статус синхронизации.

На странице отображается:

• Последний запуск — дата и время последнего запуска;
• Синхронизировано — количество синхронизированных пользователей;
• Статус — результат выполнения синхронизации.

Если настройки синхронизации не заданы, отобразится предупреждение Sync settings not configured.
Заполните раздел Настройки синхронизации и вернитесь сюда.

Кнопка Запустить синхронизацию позволяет выполнить синхронизацию вручную, не дожидаясь таймера.

Как работает синхронизация

Во время синхронизации LDAP Connector:

1. Подключается к LDAP-каталогу.
2. Получает список пользователей.
3. Сравнивает полученные данные с пользователями проекта Multifactor.
4. Передаёт новые и изменённые записи в Multifactor.
5. Сохраняет результаты выполнения синхронизации.

Активация LDAP-аутентификации в личном кабинете

После настройки LDAP Connector вернитесь в Личный кабинет, перейдите в Личный кабинет → раздел Настройки → вкладка Ldap.

В поле URL коннектора укажите внешний адрес развернутого ранее LDAP Connector.

Нажмите кнопку Проверить для тестирования соединения, после чего сохраните изменения.

После сохранения настроек пользователи смогут выполнять вход через LDAP.

Главная

На главной странице представлена краткая сводка о проекте.

Изменение логотипа на главной странице ЛК позволит персонализировать страницу входа в веб-приложения для ваших пользователей.

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

Ресурсы

В этом разделе осуществляется управление вашими информационными ресурсами и системами с многофакторной аутентификацией.

Для добавления доступны ресурсы 4-х типов: «Сайт», «Сетевой экран», «ОС/Сервер» и «Прочее».

Вы можете добавить необходимый вам тип ресурса, а в разделе настроек просмотреть данные для аутентификации и отредактировать название или адрес ресурса.

Режим совместимости

Внимание

Данный режим существует только для ресурсов типа Сайт

Для ресурсов типа Сайт добавлен переключатель Режим совместимости.

Данный режим необходим для организаций, где используются устаревшие ресурсы и приложения, не поддерживающие работу с интерфейсом Vue3 ( например устаревшие браузеры или специфичного приложения, например 1С).
Включение этого режима позволяет таким клиентам продолжать использовать MULTIFACTOR без принудительного обновления браузеров на рабочих местах.

Зайдите в Личный кабинет → выберите Ресурс типа Сайт.

В настройках появится тумблер Режим совместимости.

Важно

Активируйте режим совместимости только для тех ресурсов, где зафиксированы проблемы с отображением интерфейса. Для всех новых ресурсов по умолчанию используется современный стек (Vue3).

Сценарии использования:

Администраторы

В этом разделе ведётся управление администраторами вашей системы. Предусмотрена ролевая система доступов. Роли:

• Admin: все полномочия;
• Support 1: доступ только для чтения к разделам «Пользователи» и «Запросы доступа»;
• Support 2: доступ к разделам «Пользователи» и «Запросы доступа» с возможностью отправки ссылки на настройку второго фактора и отключения способов аутентификации пользователя;
• Support 3: доступ к разделам «Пользователи» и «Запросы доступа», полное управление пользователями за исключением импорта и экспорта.
• Support 4: включает в себя все полномочия Support 3 с возможностью пропускать пользователей без аутентификации.

При добавлении администратору придёт ссылка для первого входа, при переходе по которой он сможет установить пароль и настроить многофакторную аутентификацию.

Любого администратора, кроме себя, можно заблокировать.

Пользователи

В этом разделе отображаются ваши пользователи.

По умолчанию, сюда добавляются все ваши пользователи, которых вы направили на двухфакторную аутентификацию, но вы можете добавить пользователя вручную или массово импортировать пользователей из CSV или TXT файла.
Импортируются следующие поля :

• логин;
• почта;
• имя;
• телефон;
• последний вход;
• дата создания;
• группы пользователя;
• наличие настроенного второго фактора;
• тип аутентификации второго фактора;
• статус антиспама;
• id;
• статус LDAP;
• дополнительные поля.

При добавлении пользователя вы можете указать его имя и логин в системе, настроить принадлежность его к той или иной группе пользователей. При этом автоматически созданные пользователи попадают в системную группу All Users.

Для пользователей без указанного в явном виде имени мы подтягиваем имя из Telegram в случае, если они подключили этот метод аутентификации.

Есть возможность фильтрации пользователей по имени, группам и дополнительным фильтрам:

• Заблокированные;
• Без настроенного второго фактора;
• Без e-mail;
• Ни разу не подключались;
• Не подключались более 30 дней.

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

Вы можете отправить пользователю ссылку для настройки аутентификации, если он по какой-то причине не включил многофакторную аутентификацию ранее. При отправке настраивается время жизни ссылки, максимальное значение 48 часов (2880 минут).

Сама настройка доступов пользователя производится с помощью редактирования доступов для групп.

Статусы пользователей:

• Активный — пользователь прошел регистрацию и подключил 2FA
• Приглашение отправлено — пользователь ожидает подключения 2FA
• Заблокирован — пользователь заблокирован администратором проекта
• Временно заблокирован — пользователь временно заблокирован после нескольких неудачных попыток входа
• Приостановлено — пользователь приостановлен ввиду недостаточного количества лицензий в проекте

Поддержка мультиввода телефонных номеров в карточке пользователя

Пользователю можно добавлять несколько телефонных номеров для аутентификации по СМС.
Для этого необходимо перейти в карточку пользователя и в поле Телефоны указать необходимое количество телефонных номеров через точку с запятой. 

Важно

Ограничения:

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

Сохраняем и получаем следующее:

• В разделе Телефоны отображаются наши номера.
• В разделе Подключенные способы аутентификации имеем 3 варианта в зависимости от необходимого номера.

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

Как это выглядит при подтверждении второго фактора:

1. Пользователь выбирает метод аутентификации SMS.
2. Далее выбирает необходимый номер телефона.
3. На этот номер приходит код, который необходимо ввести в панель.

Требования к валидации поля Телефоны

• Контекст: правило обязательности (минимум 1 номер) применяется при редактировании существующей записи.
• Проверка формата: строка парсится по разделителю ;. Если любой из элементов не проходит валидацию номера — ошибка, форма не сохранится.
• Лимит: допускается от 1 до 5 номеров включительно. Выход за пределы диапазона (0 или >5) приводит к ошибке сохранения.

Создание дополнительных полей в карточке пользователя

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

Как пользоваться:

• Добавить поле: создаёт строку с Название и Значение.
• Удалить поле: кнопка × в строке.
• Сохранить: внизу формы для сохранения новой внесённой информации.

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

Группы

По умолчанию вам доступна одна системная группа доступа All Users. В нее попадают новые пользователи, созданные автоматически.

При создании и редактировании группы вы можете указать:

• название группы;
• время жизни токена доступа;
• в каком случае запрашивать второй фактор;
• методы аутентификации, доступные пользователям этой группы (не забудьте оставить доступным хотя бы один);
• ресурсы, к которым группа имеет доступ;
• IP-адреса или подсети, с которых разрешено подключение к ресурсам;
• дни недели, в которые доступ для этой группы пользователей разрешён.

Правила применения групповых политик 2FA

Политики применяются на основе членства пользователей в группах и настроек доступа к ресурсам.

Правила:

1. Область применения политик

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

2. Приоритет групп

• Пользовательские группы имеют высший приоритет по сравнению с группой AllUsers.
• Если политики определены и в AllUsers, и в пользовательских группах, применяются только политики пользовательских групп.
• При наличии политик в нескольких пользовательских группах IP-адреса из этих политик объединяются.

3. Приоритет политик внутри групп

• Правило «Всегда запрашивать» имеет наивысший приоритет.
• Если хотя бы в одной пользовательской группе установлено «Всегда запрашивать», 2FA будет запрашиваться всегда.
• При отсутствии правила «Всегда запрашивать» проверяются IP-адреса из всех пользовательских групп.

Примеры применения

Политика по IP применяется только к выбранным ресурсам

Параметры:

• Ресурс: FinanceApp
• IP пользователя: 192.168.1.100

Группы:

• AllUsers: доступ к FinanceApp, HRPortal; политика — не запрашивать 2FA для 192.168.1.100
• Developers: доступ к DevOpsServer (FinanceApp не выбран)

Результат:
Применяется политика AllUsers, 2FA не запрашивается.

Политика только в AllUsers

Параметры:

• Ресурс: HRPortal
• IP пользователя: 10.0.0.55

Группы:

• AllUsers: доступ к HRPortal; политика — запрашивать 2FA для 10.0.0.55
• Managers: доступ к FinanceApp (HRPortal не выбран)

Результат:
Применяется политика AllUsers, 2FA запрашивается.

Политики в AllUsers и пользовательской группе

Параметры:

• Ресурс: DevOpsServer
• IP пользователя: 172.16.0.20

Группы:

• AllUsers: доступ к DevOpsServer; политика — не запрашивать 2FA для IP (172.16.0.20 не в списке)
• DevOps_Team: доступ к DevOpsServer; политика — запрашивать 2FA для 172.16.0.20

Результат:
Применяется политика DevOps_Team, 2FA запрашивается.

Политики в нескольких пользовательских группах

Параметры:

• Ресурс: FinanceApp
• IP пользователя: 192.168.1.100

Группы:

• Finance_Managers: доступ к FinanceApp; политика — не запрашивать 2FA для 192.168.1.100
• Security_Team: доступ к FinanceApp; политика — запрашивать 2FA для IP (192.168.1.100 не в списке)

Результат:
IP объединяются, применяется политика Finance_Managers, 2FA не запрашивается.

 Правило «Всегда запрашивать»

Параметры:

• Ресурс: HRPortal
• IP пользователя: 10.0.0.55

Группы:

• AllUsers: доступ к HRPortal; политика — не запрашивать 2FA для 10.0.0.55
• HR_Admins: доступ к HRPortal; политика — всегда запрашивать 2FA

Результат:
Правило «Всегда запрашивать» перекрывает другие политики, 2FA запрашивается всегда.

Заключительные выводы:

Безусловный и условный запрос второго фактора

Доступны 2 варианта логики запроса второго фактора:

1. Безусловная

• Всегда запрашивать
• Никогда не запрашивать
  

2. Условная

• Запрашивать, если IP пользователя в списке (черный список)

• Не запрашивать, если IP пользователя в списке (белый список)

Последние два режима «Запрашивать, если IP пользователя в списке» и «Не запрашивать, если IP пользователя в списке» представляют соответственно черный и белый списки. Диапазоны IP предварительно настраиваются в разделе «Настройки» → «Диапазоны IP».

При вычислении итоговой политики учитываются настройки всех групп, в которых находится пользователь — системной «AllUsers» и пользовательских групп.

• при использовании в группах пользователей безусловной логики, настройки в пользовательских группах имеют более высокий приоритет, чем в системной группе AllUsers. При этом «Никогда не запрашивать» выше в приоритете, чем «Всегда запрашивать»;
• при использовании в группах пользователей разных логик (условная/безусловная), условная логика всегда выше в приоритете, чем безусловная;
• логика с чёрным списком («Запрашивать, если IP пользователя в списке») приоритетнее логики с белым списком («Не запрашивать, если IP пользователя в списке»).

Итоговую политику запроса второго фактора и доступа к ресурсам для каждого пользователя можно проверить в деталях пользователя.

Выбор способов аутентификации через мобильное приложение

Администратор может разрешить для группы сразу несколько способов аутентификации через мобильное приложение:

• PUSH
• OTP
• PUSH+OTP

Настройка для группы

1. Откройте раздел «Группы» и выберите нужную группу.
2. В блоке «Способы аутентификации» активируйте переключатель «Мобильное приложение».
3. Отметьте галочками доступные для пользователей способы подтверждения.
4. Сохраните изменения.

Поведение на стороне пользователя

• Выбор способа: Если для группы разрешено несколько способов, пользователь сможет самостоятельно выбрать подходящий на странице двухфакторной аутентификации.
• Запоминание выбора: Система запоминает последний успешно использованный способ и при следующем входе отображает его первым. Если разрешён только один способ, он применяется автоматически.

Изменение способа по умолчанию

Если пользователь хочет сменить стандартный способ аутентификации:

1. Автоматический запуск: При открытии страницы входа сначала автоматически срабатывает текущий способ по умолчанию.
2. Выбор нового метода: Пользователь выбирает новый желаемый способ авторизации.
3. Обновление в приложении:
   • Откройте мобильное приложение.
   • Смахните предыдущий запрос вниз для его отклонения.
   • Обновите список запросов с помощью свайпа сверху вниз.
4. После обновления в приложении отобразится запрос для нового выбранного способа.

Особенности для RADIUS-ресурсов

1. Для интерактивных RADIUS-ресурсов также поддерживается выбор между PUSH и OTP.
2. Если у пользователя зарегистрировано несколько мобильных устройств, в интерфейсе сначала потребуется выбрать нужное устройство, а затем — способ подтверждения.
3. Если устройство или доступный способ всего один, дальнейший выбор пропускается и выполняется автоматически с учётом режима, заданного в настройках самого ресурса.

Доступы

В этом разделе администратор системы видит все запросы доступов своих пользователей.

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

В детализированной информации о запросе доступа вы сможете найти следующие данные:

• ресурс, к которому пользователь получал доступ;
• какой способ аутентификации был выбран;
• в какое время пришёл запрос на авторизацию;
• отпечаток устройства, с которого производился запрос;
• IP адрес и геолокация.

Администратор может пропустить пользователя без авторизации. Для этого нужно зайти в детали запроса со статусом Ожидается аутентификация и нажать на кнопку Пропустить без аутентификации. Данный метод сработает только в том случае, если время жизни токена еще не истекло, а пользователь не ушёл с экрана аутентификации.

Также данным способом можно вывести пользователя из антиспама. В этом случае не важно истекла сессия или нет

Проект

В этом разделе вы можете задать описание профиля: название информационной системы и контакты администратора, к которому ваши пользователи могут обращаться за помощью.

Домен организации

Данная настройка предназначена для контроля добавления администраторов и сотрудников поддержки в проект, разрешая регистрацию только с корпоративными email-адресами указанных доменов.

Формат:

• Домены перечисляются через точку с запятой (например, multifactor.ru; mf.ru).
• Если список доменов пуст, ограничение не действует.

Ограничение ip-адресов

Данный функционал позволяет, например, ограничить доступ к личному кабинету только с корпоративных IP-адресов (офисной сети). Администратор проекта имеет возможность определить список разрешённых IP-адресов, с которых разрешён доступ в личный кабинет для ролей Admin и Support.

Поддерживаются следующие форматы указания IP-адресов:

• Одиночный IP-адрес
• Диапазон IP-адресов
• IP-подсеть

Управление доступом

• Администратор может активировать или деактивировать проверку IP-адресов.
• Если настройка включена, но список IP-адресов не задан, ограничения применяться не будут.
• Изменения вступают в силу сразу после сохранения конфигурации.

Настройки

Раздел содержит 6 вкладок, которые вы можете настраивать под свои потребности: Учётные записи, СМС, Звонки, Расширенное API, Поставщики учетных записей, Диапазоны IP.

Учётные записи

Формат имени пользователя определяет, как MULTIFACTOR будет преобразовывать учётные записи для обработки и хранения.

Варианты могут быть:

• Без преобразования: имя пользователя обрабатывается как есть.

• Active Directory: из имени пользователя убирается название домена таким образом, что «domain\user», «user@domain.local» и «user» будут обрабатываться как «user». В разделе есть переключатель «а также переименовать пользователей и удалить дубликаты (безопасно)», чтобы переименовать существующих. Логика переименования:

  1. Если в системе существует больше 1 формата УЗ одного пользователя (domain\user, user, user@domain), то выбирается одна запись по критериям:
     • с привязанным 2FA
     • с последней датой входа
  2. Далее эта запись приводится в формат Active Directory (только логин — user), остальные форматы удаляются.

СМС

По умолчанию используется СМС-шлюз MULTIFACTOR. MULTIFACTOR отправляет HTTP запрос (POST / GET ) на шлюз. Поддерживаются все основные способы авторизации.

В параметрах запроса передается телефон и код доступа (6 цифр).

Если это наш провайдер, то используется логика, зашитая в наш сервис sms.

Если же сервис внешний, то вот список токенов, вместо которых наш сервис подставляет значения. Эти токены можно использовать, например, при указании аргументов запроса во внешний сервис. Запрос GET имеет формат QUERY. Настраивает администратор заказчика в ЛК.

Внимание

Для корректной работы интеграции с внешним SMS-сервисом необходимо обеспечить исходящие TCP-соединения со следующих портов инфраструктуры приложения на указанные порты сервиса:

443/TCP — основной порт для защищённого HTTPS-взаимодействия.

444/TCP — дополнительный порт для защищённых соединений.

8090/TCP, 81/TCP, 8259/TCP, 8624/TCP — порты для служебного и управляющего API.

Из HTTP методов доступны GET и POST

В режиме POST появляются два поля:

Звонки

В данном разделе есть возможность интеграции по SIP-протоколу. По умолчанию используется SIP MULTIFACTOR. Он является основным и не требует дополнительных настроек.

Однако можно настроить собственного SIP-провайдера. Работа протестирована с АТС Asterisk (FreeBPX). Для этого нажмите Ваш поставщик SIP и введите:

1. Логин УЗ SIP-провайдера
2. Пароль УЗ SIP-провайдера
3. IP и порт сервера

Далее можете проверить соединение с SIP-провайдером, и, после успешной проверки, нажать сохранить.

Расширенное API

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

Также в нашей базе знаний есть инструкции по API для управления пользователями (субъектами доступа) и API для управления ресурсами (объектами доступа).

Поставщики учетных записей

В данной вкладке вы можете добавить и настроить SAML-поставщиков учётных записей для последующего их использования в SAML и OpenID-Connect ресурсах.

Диапазоны IP

В данной вкладке задаются диапазоны IP для использования в групповых политиках для управления запросом второго фактора на базе IP-пользователя.

Функциональность ограничения доступа по IP-адресу

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

Ключевые правила:

• Группа AllUsers — системная группа по умолчанию, включающая всех пользователей системы.
• Пользовательские группы — группы, созданные пользователями для управления доступом к определенным ресурсам.
• Политики пользовательских групп имеют приоритет над AllUsers для связанных ресурсов.
• Для ресурсов, не связанных с пользовательскими группами, применяются правила AllUsers.

Сценарии применения

Примеры настройки и работы политик

Пример 1

Группы и их настройки:

1. AllUsers:
   • Ресурсы: Доступ ко всем ресурсам.
   • Ограничение IP: Нет.
2. Группа 1:
   • Ресурсы: Доступ только к Forti.
   • Ограничение IP: Нет.
3. Группа 2:
   • Ресурсы: Доступ только к Forti2.
   • Ограничение IP: Только 192.168.0.1.

Сценарии запросов:

Запрос 3: Доступ к Forti2 с IP 192.168.0.1 → Granted (IP разрешен).

Запрос 1: Доступ к Forti с любого IP → Granted (нет ограничений).

Запрос 2: Доступ к Forti2 с IP 10.0.0.5 → Denied (несоответствие IP).

Пример 2

Группы и их настройки:

1. AllUsers:
   • Ресурсы: Доступ ко всем ресурсам.
   • Ограничение IP: 192.168.0.1.
2. Группа 1:
   • Ресурсы: Доступ только к Forti.
   • Ограничение IP: Нет.
3. Группа 2:
   • Ресурсы: Доступ только к Forti2.
   • Ограничение IP: 192.168.0.2.

Сценарии запросов:

Запрос 1: Доступ к Forti с IP 10.0.0.5 → Denied (ограничение AllUsers).

Запрос 2: Доступ к Forti2 с IP 10.0.0.5 → Denied (ограничение Группы 2).

Запрос 3: Доступ к Forti2 с IP 192.168.0.2 → Granted (соответствие IP).

Пример 3

Группы и их настройки:

1. AllUsers:
   • Ресурсы: Доступ только к Forti2.
   • Ограничение IP: 192.168.0.1.
2. Группа 1:
   • Ресурсы: Доступ только к Forti.
   • Ограничение IP: Нет.
3. Группа 2:
   • Ресурсы: Доступ только к Forti2.
   • Ограничение IP: 192.168.0.2.

Сценарии запросов:

Запрос 1: Доступ к Forti с любого IP → Granted (нет ограничений в Группе 1).

Запрос 2: Доступ к Forti2 с любого IP → Denied (ограничение Группы 2).

Запрос 3: Доступ к Forti2 с IP 192.168.0.2 → Granted (соответствие IP).

Инструкция по настройке 

Откройте раздел управления группами.

Выберите группу, для которой требуется настроить политику.

Нажмите кнопку «Редактировать»

Введите IP-адрес, диапазон или маску для ограничения доступа.

Нажмите кнопку «Сохранить».

Перейдите на вкладку «Пользователи».

Откройте профиль пользователя, состоящего в целевых группах.

Убедитесь, что политика группы применилась.

Журнал

В данной вкладке отображаются действия администраторов, а также события, выполняемые через API. В ней отображаются следующие действия:

• Вход в админ-панель
• Удаление/Создание/Изменение ресурса
• Удаление/Создание/Изменение группы
• Удаление/Добавление/Изменение сотрудника
• Удаление/Создание/Изменение списка IP-адресов
• Изменение формата имён учётных записей
• Запуск переименования учётных записей/удаления дубликатов
• Отображение секрета ресурса
• Включение/Выключение API
• Изменение секрета API
• Отображение секрета API
• Отправка ссылки на настройку 2FA

Лицензии

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

Система двухфакторной аутентификации MULTIFACTOR доступна бесплатно до 3-х пользователей (включительно).

Приложение

Данный раздел предназначен для кастомизации приложения Multifactor, а также для возможности интеграции собственного приложения.

Важно

SDK является компонентом решения MULTIFACTOR. Если вы хотите подключить SDK для вашего мобильного приложения, необходимо приобрести данный продукт MULTIFACTOR.

Обратитесь к менеджеру или оставьте заявку — мы подскажем, с чего начать.

Настройка SDK для двухфакторной аутентификации

Клиентам предоставляется возможность разработки собственных приложений для использования второго фактора аутентификации. Для этого реализован Software Development Kit (SDK) и интерфейс его конфигурации.

Требования к безопасности мобильного приложения

Важно

Для корректной работы SDK Мультифактор в Вашем мобильном приложении должна быть реализована обязательная проверка наличия системной блокировки экрана (Secure Lock) на устройстве пользователя.

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

• Действия пользователя: 
  • Пользователь направляет запрос администратору проекта на предоставление ссылки для выполнения процедуры настройки второго фактора.
• Действия администратора:
  • Найти учетную запись целевого пользователя в Личном Кабинете.
  • Удалить привязанное мобильное приложение пользователя.
  • Отправить пользователю ссылку для настройки аутентификации.

Процедура привязки дополнительного устройства осуществляется аналогично процессу первичной настройки. 

Для настройки SDK необходимо:

1. Перейти в раздел личного кабинета Приложение;
2. переключить Использовать собственное мобильное приложение для 2FA на Да;
3. далее нажать Настроить SDK

Внимание

При использовании собственного приложения (в настройке выбрано Да) все push-уведомления будут приходить только через настроенное приложение. На мобильное приложение Multifactor push-уведомления приходить не будут.

Если же настройка отключена (в настройке выбрано Нет) все push-уведомления будут приходить на мобильное приложение Multifactor.

При инициализации процесса настройки выполняется проверка наличия заполненного адреса электронной почты пользователя в  поле email.

Если проверка успешна, то происходит перенаправление в административную панель Multipushed для дальнейшей настройки приложения.

Внимание

Дополнительная регистрация в Multipushed не требуется. На стороне системы Мультифактор формируется Access Token для доступа к административной панели Multipushed с временем жизни 90 минут.

Далее необходимо:

1. Перейти в раздел Приложение;
2. Выбрав необходимое приложение, нажать Параметры.

После чего откроется настройка конфигурации для приложения.

Основные настройки:

1. Название приложения.
2. Максимальный период времени, в течении которого будет происходить попытка отправки.
   Задается в секундах, должен быть в диапазоне от 30 до 86400 (24ч).
3. Количество дней, после которых неактивный токен будет переведен в статус suspend.
4. Настройка омниканальности. Настройка производится в зависимости от канала связи, используемого приложением.

Внимание

Параметры настраиваются опционально в соответствии с набором каналов связи, задействованных в приложении.

Подробнее об омниканальности, а также настройки каналов связи можете ознакомиться в документации Multipushed.

После настройки омниканальности, необходимо нажать Сохранить

Система сообщит об успешном сохранении конфигурации, а push-уведомления будут приходить через настроенное приложение.

Интеграция SDK с мобильным приложением

Рекомендуемый способ (Gradle 7+, Kotlin DSL) — в корневом файле `settings.gradle.kts` внутри блока `dependencyResolutionManagement { repositories { ... } }`:

// settings.gradle.kts (root)
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
        maven { url = uri("https://jitpack.io") }

        // MultiFactor Maven (публичный)
        maven {
            url = uri("https://multifactor.ru/public/mf")
        }

        // (опционально) локальный кэш, куда публикуется AAR при локальной сборке SDK
        maven { url = uri("${rootDir}/build/repo") }
    }
}


Для проектов на Groovy DSL или старых версиях Gradle можно добавить в корневой `build.gradle`:

// build.gradle (project)
allprojects {
    repositories {
        google()
        mavenCentral()
        maven { url 'https://jitpack.io' }
        maven {
            url 'https://multifactor.ru/public/mf'
        }
    }
}

// build.gradle.kts
dependencies {
    implementation("ru.multifactor:multifactor-android-sdk:1.0.6") // укажите актуальную версию
}

class MainApplication : Application() {
    private val scope = CoroutineScope(Dispatchers.Main)
    override fun onCreate() {
        super.onCreate()
        scope.launch {
            MultiFactor.init(
                context = applicationContext,
                region = "ru", // "ru" | "kz" | "dev"
                onAccessRequest = { request ->
                    // Покажите UI для обработки запроса
                }
            )
        }
    }
}

val mf = MultiFactor.getInstance()

val active = MultiFactor.getActiveAccessRequest()

val requestId = "ID_ЗАПРОСА"

// Подтвердить запрос (с OTP, если требуется)
val approved = MultiFactor.approveAccessRequest(requestId, "123456" /* otp */)

// Отклонить запрос
val rejected = MultiFactor.rejectAccessRequest(requestId)

try {
    // registerRequestId получается из QR-кода или ссылки
    val newAccount = MultiFactor.registerAccount(registerRequestId)
    if (newAccount != null) {
        // Учетная запись успешно добавлена
    }
} catch (e: Exception) {
    // Обработка ошибок
}

val accounts = MultiFactor.getAccounts()

val success = MultiFactor.deleteAccount("ID_АККАУНТА")

MultiFactor.askPermissions()

pod 'MultiFactor','1.0.9'

import UIKit
import MultiFactor

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Инициализация SDK
        Task {
            do {
                try await MultiFactoriOS.shared.initialize(region: "ru") { accessRequest in
                    // Обработка входящего запроса на доступ
                    print("Новый запрос на доступ: \(accessRequest.message)")
                    
                    // Здесь можно показать Alert или открыть экран подтверждения
                    DispatchQueue.main.async {
                        self.showAccessRequestAlert(accessRequest)
                    }
                }
            } catch {
                print("Ошибка инициализации SDK: \(error)")
            }
        }
        
        return true
    }
    
    private func showAccessRequestAlert(_ request: AccessRequest) {
        // Реализация показа алерта
    }
}

Task {
    do {
        // registerRequestId получается из QR-кода или ссылки
        let account = try await MultiFactoriOS.shared.registerAccount(
            registerRequestId: "your-request-id"
        )
        
        if let account = account {
            print("Аккаунт зарегистрирован: \(account.identity ?? "Unknown")")
        } else {
            print("Не удалось зарегистрировать аккаунт")
        }
    } catch {
        print("Ошибка: \(error)")
    }
}

Task {
    do {
        let accounts = try await MultiFactoriOS.shared.getAccounts()
        for account in accounts {
            print("ID: \(account.id)")
            print("Identity: \(account.identity ?? "N/A")")
            print("Scope: \(account.scope ?? "N/A")")
            print("Status: \(account.status ?? "N/A")")
        }
    } catch {
        print("Ошибка: \(error)")
    }
}

Task {
    do {
        let success = try await MultiFactoriOS.shared.approveAccessRequest(
            requestId: "request-id"
        )
        
        if success {
            print("Запрос подтвержден")
        } else {
            print("Не удалось подтвердить запрос")
        }
    } catch {
        print("Ошибка: \(error)")
    }
}

MultiFactoriOS.shared.askPermissions()

Доставка push-уведомлений через собственные каналы

В дополнение к стандартной доставке push-уведомлений через сервис Pushed, платформа Multifactor поддерживает интеграцию через собственный канал заказчика. В этой модели Multifactor не инициирует отправку push самостоятельно, а уведомляет заказчика о необходимости отправки через webhook — HTTP-запрос на заданный адрес. Заказчик получает уведомление и доставляет push пользователю через свою инфраструктуру.

Общие сведения

• Принцип работы: При поступлении запроса на доступ Multifactor отправляет POST-запрос на заданный адрес заказчика. Заказчик получает уведомление и доставляет push пользователю через собственную инфраструктуру.
• Автономность: Функционал «Антиспама» не влияет на отправку webhook — уведомление отправляется при каждом запросе на вход.
• API: Регистрация устройства и callback-процедура (подтверждение/отклонение входа) проходят через API Multifactor без изменений.

Важно

Настройка доступна в личном кабинете Мультифактора с активированным SDK. Как только SDK включен, отобразится тумблер Использовать собственный канал push и поле для ввода вебхука.

Особенности реализации

• Функционал доступен только при включенном SDK.
• При активации собственного канала адрес webhook обязателен.
• Использование HTTP без шифрования (без HTTPS) приведет к ошибке сохранения.
• При отключении функционала адрес webhook обнуляется.

Обработка результата отправки

• Если webhook-приёмник заказчика ответил успешно (Статус 2xx), событие считается доставленным.
• Если приёмник недоступен, ответил ошибкой (в т.ч. Статус 5xx) или превышен таймаут, доставка считается неуспешной. Запрос на вход не подтверждается, возвращается ошибка. Пользователь не получит запрос, вход будет отклонён (либо завершится по таймауту ожидания).

Функционал Антиспама на отправку webhook не влияет — webhook отправляется всегда, в отличие от push через MultiFactor.

Особенности функционала

• Push-токен устройства в webhook-модели Multifactor не использует и не хранит push-токены устройств. — доставку осуществляются силами заказчика, сопоставление аккаунт → push-токен ведётся на его стороне.
• Содержимое push (заголовок, текст) формирует заказчик — в webhook оно не передаётся.
• Регистрация устройства и callback проходят через API Multifactor без изменений.
• Проверки, связанные с доставкой push через Multifactor (наличие push-токена устройства, наличие AccessToken Pushed) для webhook не применяются, так как Multifactor push не отправляет.

Пошаговая настройка интеграции

1. Подготовка webhook-приемника: Реализуйте на стороне бэкенда HTTP-эндпоинт (POST, application/json), принимающий уведомления.

• Метод: POST
• Content-Type: application/json
• Протокол: только HTTPS
• Тело запроса:

 {
      "RequestId": "string",
      "AccountId": "string",
      "IsMobilePushOtpCodeRequired": true | false
  }

где:

•  Статус 2xx — если уведомление принято в обработку.
• Любой НЕ 2xx (в т.ч. Статус 5xx) или отсутствие ответа в течение 5 секунд Multifactor трактует как неуспешную доставку, и запрос доступа будет отклонён.

Эндпоинт только принимает уведомление и запускает отправку push. Решение пользователя в ответе на webhook возвращать не нужно — оно приходит отдельно через SDK.

2. Настройка мобильного приложения: Приложение со встроенным SDK должно быть настроено на прием push-уведомлений через собственный сервис (FirebaseMessagingService) с последующей передачей данных в SDK.

3. Конфигурация в Личном кабинете: В разделе Настройка SDK Вашего ЛК:

• Активируйте переключатель Использовать собственный канал push.
• Укажите URL Вашего webhook-приемника.

После этого уведомления о новых запросах доступа пойдут через webhook.

4. Обработка событий: После получения webhook Ваш бэкенд должен по AccountId идентифицировать устройство пользователя, сформировать содержимое push-уведомления (заголовок/текст) и отправить его через свой канал.

5. Показ уведомления: Push приходит на устройство, приложение (через SDK) показывает запрос на подтверждение входа.

6.Возврат решения: Пользователь подтверждает/отклоняет; SDK возвращает решение в API MultiFactor (callback) — без дополнительной реализации со стороны заказчика.

Бесшовная интеграция с мобильным приложением

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

Цветовая тема и логотип

Чтобы настроить схему:

1. переключите параметр на Настраиваемая;
2. задайте цвета: общего фона, фона плашек аккаунтов и всплывающих диалоговых окон, шрифта, а также иконок и некоторых графических элементов;
3. сохраните ее и потяните вниз экран в вашем мобильном приложении Мультифактор

Также можно настроить свой логотип, переключив параметр на свой логотип.

Архив

Данный раздел предназначен для создания резервных копий данных Личного Кабинета и их последующего выборочного восстановления обратно в основную базу данных. Это обеспечивает защиту данных от потери и позволяет администрировать их состояние.

В резервную копию попадут следующие данные:

• данные пользователей (включая настройки 2FA);
• группы и права доступа;

Архитектура работы 

Из административного интерфейса инициируется HTTP-запрос, на постановку в очередь задачи: создание резервной копии или же восстановления.

Операция резервного копирования:

1. Сервис проверяет возможность постановки задачи, затем сохраняет задачу и создает сущность Backup/Restore со статусом Старт.
2. Как только задача переходит в статус В процессе, Личный Кабинет замораживается. Личный Кабинет переводится в режим только для чтения, чтобы обеспечить целостность данных во время операции.
3. Создается сжатый архив, который загружается в объектное хранилище.
4. По завершению создания архива задача переходит в статус Выполнено. В этот момент Личный кабинет снова будет доступен для редактирования, а на почту администратора придёт сообщение с результатом создания резервной копии.

Внимание

В режиме только для чтения нельзя выполнять операции изменения Личного кабинета (создание, редактирование, удаление), как через сам личный кабинет, так и через API.

Операция восстановления:

1. Запрашиваемый архив загружается из хранилища со статусом Старт.
2. Данные восстанавливаются из архива во временную базу данных со статусом В процессе, а Личный Кабинет замораживается.
3. Производится сравнение данных во временной и основной базах, после чего необходимые изменения применяются в основной базе данных.
4. По завершению восстановления Личного Кабинета задача переходит в статус Выполнено. В этот момент Личный кабинет снова будет доступен для редактирования, а на почту администратора придёт сообщение с результатом восстановления из резервной копии.

Внимание
При восстановлении из резервной копии все текущие данные в кабинете будут удалены и заменены данными из архива.

Если вы используете синхронизацию УЗ (сервис DirectorySync), то для создания резервной копии, а также восстановления проекта из резервной копии необходимо выполнить следующие шаги:

1. Отключить синхронизацию УЗ.
2. Запустить восстановление проекта, дождаться успешного завершения операции.
3. Сбросить кэш сервиса DirectorySync.
4. Снова включить синхронизацию УЗ.

2FA Регистрации

Данный раздел предназначен для предоставления администратору прозрачной истории всех запросов на настройку 2FA.
Это позволяет:

1. Отслеживать статусы запросов.
2. Идентифицировать потенциально подозрительные активности
3. Управлять активными процессами настройки.

Раздел содержит в себе следующие параметры:

• Дата — дата и время создания запроса на настройку 2FA.
• Идентификатор пользователя — для которого был инициирован запрос.
• Статус запроса — текущий статус запроса.

Если запрос находится в одном из активных статусов, предоставляется возможность отозвать запрос на настройку второго фактора.

Существуют следующие статусы: