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

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

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

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

Вход

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

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

Главная

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

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

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

Ресурсы

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

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

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

Админы и поддержка

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

• 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
• Заблокирован — пользователь заблокирован администратором проекта
• Временно заблокирован — пользователь временно заблокирован после нескольких неудачных попыток входа
• Приостановлено — пользователь приостановлен ввиду недостаточного количества лицензий в проекте

Группы

По умолчанию вам доступна одна системная группа доступа 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 пользователя в списке»).

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

Запросы доступа

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

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

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

• ресурс, к которому пользователь получал доступ;
• какой способ аутентификации был выбран;
• в какое время пришёл запрос на авторизацию;
• отпечаток устройства, с которого производился запрос;
• 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 для двухфакторной аутентификации

Клиентам предоставляется возможность разработки собственных приложений для использования второго фактора аутентификации. Для этого реализован Software Development Kit (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()

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

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

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

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

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

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

Архив

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

Сессии настройки

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

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

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

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

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

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