Настройки аутентификации#

Настройки аутентификации задаются в разделе «Аутентификация» консоли управления.

:size=80% — Настройки аутентификации – вкладка «Общие настройки»#

Настройки аутентификации разделены по вкладкам:

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

На вкладке «Общие настройки» можно задать:

уровень аутентификации по умолчанию – укажите «Первый фактор», чтобы у пользователей запрашивалась только проверка первого фактора аутентификации (кроме пользователей, в настройках которых включена необходимость проверки второго фактора). Укажите «Первый и второй фактор», чтобы для пользователей дополнительно к первому фактору требовалась проверка второго фактора аутентификации;
параметры продолжительности сессии:
- продолжительность сессии при бездействии пользователя;
- максимальная продолжительность сессии.
режим запоминания учетных записей – укажите «Запоминать одну учетную запись», чтобы каждый вход новой учетной записью в браузере перезаписывал запомненный вход предыдущей учетной записи или «Запоминать все учетные записи», чтобы каждый вход новой учетной записи добавлял к списку запомненных учетных записей в браузере еще одну;
отображаемое имя пользователя – имя пользователя, которое отображается на странице входа. Задается в виде регулярного выражения, например: ${family_name-} ${given_name-}. Такое регулярное выражение позволяет отображать фамилию и имя пользователя, сохраненные в атрибутах family_name и given_name;
отображаемый идентификатор пользователя – идентификатор учетной записи, который отображается второй строчкой на странице входа. Задается в виде регулярного выражения, например: ${email-$phone_number}. Такое регулярное выражение позволяет отображать один из контактов, сохраненных в атрибутах email или phone_number (если имеются оба, то отображается email). При настройке можно использовать маскирование значений. Например, правило ${phone_number&maskInMiddle(3,3)} будет отображать средние числа номера телефона в виде *;
признак необходимости отображать аватар на странице входа;
время отображения экрана логаута (в секундах) – сколько времени пользователю будет показан экран выхода до автоматического перенаправления пользователя на страницу перехода в приложение после логаута.

Настройка парольной политики#

Парольные политики настраиваются на вкладке «Парольные политики» раздела «Аутентификация» консоли управления.

Предусмотрены следующие настройки:

Минимальная длина пароля – число символов в пароле (рекомендуется не менее 8);
Словарь паролей – указывается текстовый файл, содержащий список запрещенных паролей. Каждый пароль должен быть на отдельной строке. В случае использования больших файлов рекомендуется загружать их непосредственно на сервер, и задавать путь к файлу в настройке dicPath в блоке настроек blitz.prod.local.idp.password-policy в файле blitz.conf.
Группа символов – задает минимально необходимое количество групп символов в пароле. По каждой группе символов можно задать настройки в таблице групп символов:
- Допустимые символы – с помощью регулярного выражения задается множество символов группы. Например, можно расширить допустимые символы цифр, изменив регулярное выражение на следующее – [0-9٠-٩], можно расширить допустимые наборы символов букв – [a-zа-я] и [A-ZА-Я], добавить или убрать допустимые спецсимволы – [!@#$%^&*()+-?.,;:’`“{}[]><=~/\_].
- Минимум символов – сколько минимум символов из группы должно использоваться в пароле, что считалось, что группа задействована в пароле.
Запрет использования старых паролей – настройка указывает, какое количество старых паролей должно запоминаться, чтобы при задании нового пароля не допускать ввод пароля из истории использованных паролей.
Минимальное время жизни пароля – минимальное время жизни пароля, в секундах; пока это время не истекло, пользователю не будет разрешено поставить новый пароль. Если такую проверку не следует выполнять, то нужно задать пустое значение настройки.
Максимальное время жизни пароля – максимальное время жизни пароля, в секундах; как только это время истечет, пользователю потребуется задать новый пароль. Если такую проверку не следует выполнять, то нужно задать пустое значение настройки.
Минимальное число отличающихся символов – сколько измененных символов должно быть в новом пароле по сравнению с предыдущим (для случаев, когда пользователь меняет текущий пароль на новый). Если такую проверку не следует выполнять, то нужно задать пустое значение настройки.

Настройка ключей безопасности#

Blitz Identity Provider позволяет использовать для идентификации и аутентификации ключи безопасности (WebAuthn, Passkey, FIDO2, U2F).

Ключи безопасности настраиваются на вкладке «Ключи безопасности» раздела «Аутентификация» консоли управления.

Предусмотрены следующие настройки:

Имя системы аутентификации – необходимо задать подходящее для отображения пользователям имя системы аутентификации или имя приложения.
Домен системы аутентификации – должен совпадать с доменом, используемым системой аутентификацией или быть вышестоящим доменом. На этот домен будут выпускаться ключи безопасности.
Алгоритмы подписи – рекомендуется как минимум указать алгоритмы ES256 и RS256, чтобы обеспечивалась работа с Passkey, Windows Hello и большинством распространенных аппаратных FIDO2 и U2F ключей безопасности.
Ограничение разрешенных средств аутентификации – при значении «Не выбрано» средства аутентификации не ограничиваются. Если выбрать «Переносные», то будут работать только аппаратные ключи безопасности (подключаемые по USB, Bluetooth или NFC). Если выбрать «Встроенные в платформу», то будут работать только встроенные в устройства ключи безопасности (Windows Hello, Touch ID на MacBook, Touch ID и Face ID в мобильных телефонах, а также использование телефона как средства аутентификации с подключением по Bluetooth).
Режим проверки наличия ключа – при выборе «Обнаружение браузером» пользователю будут показываться все доступные на его устройстве для домена системы аутентификации ключи безопасности. При выборе «Обнаружение сервером» у пользователя будет запрошен логин, после чего будут показаны только те ключи, которые доступны на устройстве и привязаны к учетной записи пользователя на сервере.
Время ожидания – указывается время в миллисекундах, в течение которого система аутентификации будет ожидать от браузера ответа на запрос обращения к ключу безопасности.
Отображаемое имя пользователя – задает шаблон со строками подстановки, в соответствии с которым на странице входа по ключу безопасности в системе аутентификации отображается имя запомненного пользователя (актуально при использовании режиме «Обнаружение сервером»).
Отображаемый идентификатор учетной записи – задает шаблон со строками подстановки, в соответствии с которым на устройстве пользователю показывается имя ключа безопасности.
Нормальный сдвиг счетчика аутентификации – настройка, которая определяет, что сервер аутентификации будет сравнивать счетчик количества аутентификаций на устройстве со счетчиком количества аутентификаций этим же ключом на сервере и в случае расхождения более чем на число, указанное в счетчике, запретит использование ключа безопасности (защита от клонирования ключа).

Сервер аутентификации Blitz Identity Provider стандартно сконфигурирован таким образом, что в нем настроено доверие ко всем известным на момент выпуска текущей версии Blitz Identity Provider корневым и промежуточным сертификатам TPM модулей, FIDO, а также актуальным сертификатам Apple и Google, необходимым для проверки подписи аттестационных объектов FIDO2 и U2F. При необходимости скорректировать разрешенные аттестационные сертификаты необходимо выполнить настройки согласно Сертификаты поставщиков WebAuthn, Passkey, FIDO2, U2F.

После настройки ключей безопасности необходимо сконфигурировать методы аутентификации с использованием ключей безопасности (см. Вход с помощью ключей безопасности (WebAuthn, Passkey, FIDO2) и Подтверждение входа с помощью ключей безопасности (WebAuthn, Passkey, FIDO2, U2F)).

Настройка доступных методов аутентификации#

Методы аутентификации сгруппированы к первому, либо ко второму фактору (второй фактор используется для «усиления» первого фактора, например, пользователю в дополнение к паролю требуется ввести специальный код, сгенерированный мобильным приложением). Чтобы включить метод аутентификации, его нужно сначала настроить.

Доступные для настройки методы первого фактора и второго фактора приведены на вкладках «первый фактор» и «второй фактор». Набор методов может отличаться в зависимости от типа используемой лицензии. Для перехода к настройкам метода нужно нажать кнопку «Перейти к конфигурации метода» (при первичной настройке метода) либо ссылку «Перейти к настройкам» (для корректировки текущих заданных настроек).

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

Вход по логину и паролю#

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

Для создания правила используется строка подстановки: ${login} – это строка, введенная пользователем в поле «логин». В результате, например, правило «email=${login}» означает, что строка, введенная пользователем, будет сравниваться с атрибутом email в хранилище данных;

В настройках входа по логину и пароля можно включить проверку на соответствие пароля парольной политике (см. Настройки в файле blitz.conf). Вводимый пользователем пароль будет в момент входа проверяться на соответствие парольной политике. В случае несоответствия пароля требованиям политики пользователь сможет задать новый пароль или пропустить этот шаг.

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

выбрать опцию «Всегда проверять текущий пароль пользователя на соответствие парольной политике» или вписать имя некоторого заголовка в поле «Проверять при наличии HTTP заголовка» (в этом случае, если HTTP-запрос будет содержать указанный заголовок со значением true, то текущий пароль пользователя будет проверен на соответствие парольной политике);
опция «Разрешить пользователю пропустить смену пароля, не соответствующего парольным политикам» позволяет пользователю отказаться от смены пароля при входе;
указать количество неудачных попыток для временной блокировки. После указанного количества неудачных попыток будет установлена временная блокировка пользователю на использование данного метода аутентификации;
длительность временной блокировки (в минутах).

:size=70% — Настройка проверки на соответствие пароля парольной политике при входе#

В настройках входа по логину и пароля можно управлять защитой от перебора пароля. При включенной защите замедляется проверка пароля. После ввода пароля пользователь будет ожидать проверки в течение заданного периода «Время задержки» (в секундах).

Администратор в настройке «Защита» может выбрать следующие режимы защиты:

Автоматический режим на уровне системы и пользователей – защита включится для всех пользователей, если доля неуспешных аутентификаций превысит «Порог включения системной защиты», и выключится, если доля неуспешных аутентификаций станет ниже «Порог выключения системной защиты»;
Автоматический режим на уровне пользователей – защита сработает в отношении пользователей, по которым будет превышено число неуспешных проверок пароля, заданное настройкой «Порог включения пользовательской защиты»;
Задержка аутентификации для всех пользователей – защита будет включена для всех пользователей;
Отключена – защита будет выключена.

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

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

Для усложнения автоматического подбора пароля можно включить в Blitz Identity Provider настройки «Доказательство выполнения работы». Тогда при каждом входе по логину и паролю браузер пользователя должен будет выполнить вычислительно сложную задачу. Если не предоставить решение, предоставить неправильное решение или предоставить решение не вовремя, то Blitz Identity Provider вернет ошибку. В итоге нельзя будет понять, правильные ли логин и пароль.

В блоке настроек «Доказательство выполнения работы» можно настроить следующее:

включить настройку «Запрашивать доказательство выполнения работы».
при необходимости задать настройку «Запрашивать только при наличии HTTP заголовка» – это полезно, если нужно оставить возможность автотестам выполнять вход по паролю без необходимости прохождения проверки. В этом случае на веб-сервере нужно для пользовательских запросов настроить установку заголовка из этой настройки, а для запросов, приходящих от автотестов, заголовок не устанавливать.
установить «Показатель сложности работы» – задается значение коэффициента от 1 до 160 бит. Каждый бит увеличивает сложность в 2 раза. Рекомендуется значение 15 бит.
«Максимальный срок решения» – время в секундах, за которое браузер должен прислать результат работы. Если значение не задано, то решение задачи ожидается за 1800 секунд. Время отсчитывается с момента генерации задачи сервером в момент отображения страницы входа.

После установки настройки перед сохранением рекомендуется нажать кнопку «Тестовый расчет», чтобы получить примерное представление о времени выполнения работы на текущем устройстве.

В блоке «Правила выбора хранилища атрибутов» можно настроить правила, при выполнении которых поиск пользователя будет осуществляться только в указанном хранилище. По умолчанию поиск пользователей для аутентификации происходит во всех активных хранилищах атрибутов. Можно задать несколько альтернативных правил выбора хранилища. Это позволит аутентифицировать одних пользователей через одно хранилище, а других – через другое. Для создания правила используются строки подстановки.

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

Вход с помощью средства электронной подписи#

Настройка метода аутентификации в консоли управления#

При использовании для аутентификации средства электронной подписи необходимо:

в блоке настроек «Сертификаты» загрузить сертификаты удостоверяющих центров, подтверждающих подлинность сертификатов ключей электронной подписи или настроить взаимодействие с внешним сервисом проверки электронной подписи (см. Электронная подпись).
настроить в блоке «Правила соответствия» параметры сопоставления учетной записи пользователя в хранилище по его атрибутам из сертификата электронной подписи. В правилах сопоставления используются строки подстановки. Например, правило cn=${SUBJECT.CN} означает, что атрибут SUBJECT.CN сертификата будет сравниваться с атрибутом cn в хранилище данных. Возможно указание нескольких условий одновременно, а также указание альтернативных правил.

При конфигурировании входа по электронной подписи можно также указать:

следует ли этот метод использовать в качестве первого и второго фактора. Если да, то пользователь, прошедший аутентификацию по электронной подписи, будет считаться прошедшим двухфакторную аутентификацию (пример настройки на рисунке ниже);
следует ли проверять действительность сертификата. В этом случае Blitz Identity Provider, используя указанную в сертификате точку распределения списка отзыва (CRL), будет проверять, не был ли сертификат отозван. Для активации этой возможности следует отметить чекбокс «Проверять, что сертификат пользователя не отозван»;
следует ли создавать (регистрировать) учетную запись при первом входе по электронной подписи. В этом случае, если пользователь не найден по определенным правилам соответствия, то ему будет предложено зарегистрировать учетную запись. Чтобы включить эту функцию, следует отметить чекбокс «Создавать учетную запись, если пользователь не найден по сертификату электронной подписи» и настроить правила регистрации пользователя – каким образом заполнять атрибуты в хранилище из атрибутов сертификата. Для задания правил следует использовать строки подстановки. Например, правило email=${SUBJECT.E} означает, что в атрибут email будет сохранена электронная почта из сертификата электронной подписи пользователя.

Использование и обновление плагина#

Для корректной работы входа по электронной подписи на компьютерах пользователей используется специальный плагин – Blitz Smart Card Plugin. При первом входе по электронной подписи пользователю будет предложено установить плагин. После загрузки файла и его запуска пользователю следует пройти все шаги установки плагина. При повторном входе с данного устройства не потребуется устанавливать плагин заново.

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

При необходимости обновить версию Blitz Smart Card Plugin следует заменить дистрибутивы плагина – они размещены в директории assets с установкой Blitz Identity Provider, в архиве assets.zip. Структура архива имеет следующий вид:

plugins/sc/deb/BlitzScPlugin.deb
plugins/sc/rpm/BlitzScPlugin.rpm
plugins/sc/win/BlitzScPlugin.msi
plugins/sc/mac/BlitzScPlugin.pkg
plugins/sc/mac/BlitzScPlugin-10.14.pkg
...

Необходимо распаковать архив assets.zip, заменить файлы с дистрибутивом плагина и заархивировать обратно файлы в assets.zip.

Также можно при необходимости скорректировать настройки использования плагина электронной подписи (см. Вызов плагина ЭП).

Вход через внешние сервисы идентификации#

Перечень доступных внешних сервисов идентификации зависит от редакции Blitz Identity Provider и приобретенных опций.

Возможен вход с использованием следующих внешних сервисов идентификации:

поставщика идентификации Apple ID;
поставщика идентификации социальной сети Facebook [1];
поставщика идентификации социальной сети ВКонтакте;
поставщика идентификации Яндекс;
поставщика идентификации Google;
поставщика идентификации социальной сети Одноклассники;
поставщика идентификации Mail.ru (Mail ID);
поставщика идентификации ЕСИА (gosuslugi.ru);
поставщика идентификации ЕСИА в режиме «Цифровой профиль» (gosuslugi.ru);
поставщика идентификации Сбер ID;
поставщика идентификации Tinkoff ID;
поставщика идентификации ВТБ ID;
поставщика идентификации СберБизнес ID;
поставщика идентификации Альфа ID;
поставщика идентификации Mos ID (СУДИР);
поставщика идентификации, работающего по OpenID Connect;
поставщика идентификации, работающего по SAML.

Подключения к внешним сервисам идентификации должны быть предварительно сконфигурированы в консоли управления в разделе «Поставщики идентификации» (см. Вход через внешние поставщики идентификации).

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

Вход с помощью прокси-аутентификации#

Прокси-аутентификация (аутентификация с помощью прокси-сервера) производится по данным, передаваемым в HTTP-заголовках.

Важно

При включенной прокси-аутентификации Blitz Identity Provider производит только идентификацию пользователя, тогда как аутентификацию (в результате проверки сертификата) осуществляет прокси-сервер. Включение данного метода аутентификации допустимо в тех случаях, когда все пользователи обращаются к Blitz Identity Provider через прокси-сервер.

Для корректной работы метода необходимо указать:

требуемые HTTP-заголовки – перечень HTTP-заголовков, которые должны присутствовать для прохождения прокси-аутентификации пользователя,
HTTP-заголовок с сертификатом пользователя (опциональный параметр) – заголовок, содержащий x.509 сертификат пользователя,
соответствие значений HTTP-заголовков и идентификационных данных пользователя в хранилище атрибутов.

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

Пример настроек входа с помощью прокси-аутентификации представлен ниже:

Вход с помощью сеанса операционной системы#

Способ входа с использованием сеанса операционной системы позволяет пользователям не проходить дополнительно идентификацию и аутентификацию в Blitz Identity Provider, если они ранее вошли со своего ПК в сеть организации и прошли идентификацию и аутентификацию в операционной системе (вошли в сетевой домен). Такие пользователи получат возможность сквозной идентификации при доступе ко всем приложениям, подключенным к Blitz Identity Provider.

Для входа с помощью сеанса операционной системы в организации должен быть развернут Kerberos-сервер (отдельно или в составе контроллера домена организации) и выполнены следующие настройки (см. описания далее в подразделах):

Настройки контроллера домена (Kerberos-сервера)
Настройки в консоли управления Blitz Identity Provider.
Настройки браузеров пользователей.
Настройки запуска приложений Blitz Identity Provider.
Настройки веб-сервера.

Настройки контроллера домена (Kerberos-сервера)#

В контролере домена необходимо зарегистрировать учетную запись для сервера Blitz Identity Provider. Для созданной учетной записи нужно на странице «Account» в блоке «Account options» оснастки контроллера домена включить настройки «User cannot change password» и «Password never expires».

Также следует отметить опции «This account supports Kerberos AES 256 bit encryption» и запретить предварительную аутентификацию «Do not require Kerberos preauthentication».

В оснастке управления групповыми политиками следует настроить политику «Configure encryption types allowed for Kerberos», указав следующие возможные значения: RC4_HMAC_MD5, AES128_HMAC_SHA1 и AES256_HMAC_SHA1.

Пример настройки:

Далее необходимо создать Service Principal Name (SPN) для идентификации сервера Blitz Identity Provider сервером Kerberos. Это выполняется с помощью следующей команды:

ktpass -princ HTTP/idp.company.ru@DOMAIN.LOC -mapuser DOMAIN\blitzidpsrv -out C:\temp\spnego_spn.keytab -mapOp set -crypto ALL -ptype KRB5_NT_PRINCIPAL /pass SecretPassword

Параметры команды ktpass:

значение параметра mapuser – имя созданной в домене учетной записи сервера Blitz Identity Provider, например, DOMAIN\blitzidpsrv;
значение параметра princ – имя SPN сервера с Blitz Identity Provider для идентификации в среде Kerberos. Это имя состоит из имени хоста сервера с Blitz Identity Provider, имени Kerberos Realm в верхнем регистре (обычно совпадает с именем домена) и используемого транспортного протокола (HTTP). Пример значения SPN – HTTP/idp.company.ru@DOMAIN.LOC. Важно, чтобы HTTP/ в начале имени SPN указывалось именно большими буквами, как в примере.
параметр mapOp – если задан в значение add, то новый SPN будет добавлен к существующим. Если задано значение set, то SPN будет перезаписан.
параметр out – задает путь к генерируемому keytab-файлу. Например, C:\temp\spnego_spn.keytab;
параметр /pass – значение пароля от учетной записи сервера Blitz Identity Provider в домене.
параметры crypto и ptype задают ограничения на используемые алгоритмы и тип генерируемой Kerberos-службы. Рекомендуется задать параметры как в указанном примере -crypto ALL -ptype KRB5_NT_PRINCIPAL.

Сгенерированный keytab-файл необходимо сохранить. Он будет необходим для последующей настройки в консоли управления Blitz Identity Provider.

Настройки в консоли управления Blitz Identity Provider#

Необходимо перейти в консоли управления в разделе «Аутентификация» к настройкам способа входа «Вход по сеансу операционной системы». В открывшемся окне необходимо загрузить сгенерированный ранее keytab файл. Имя SPN при этом будет задано автоматически в соответствии с загруженным файлом.

По результатам загрузки keytab-файла будет отображаться информация о соответствующей Kerberos-службе.

При необходимости можно:

удалить загруженный keytab-файл;
загрузить еще keytab-файлы, в случае подключения Blitz Identity Provider к нескольким контроллерам домена.

Далее необходимо определить параметры соответствия Kerberos-токена (TGS) и учетной записи в Blitz Identity Provider.

Например, можно задать соответствие, что получаемый из Kerberos-токена идентификатор пользователя (username) должен соответствовать атрибуту sAMAccountName, получаемому из LDAP-каталога (Microsoft Active Directory).

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

Blitz Identity Provider предоставляет два возможных сценария использования входа по сеансу операционной системы:

Основной сценарий. Пользователи входят в операционную систему, и после этого должны сквозным образом входить во все приложения, подключенные к Blitz Identity Provider. Предоставлять пользователям возможность войти в приложения под другой учетной записью не требуется. В этом случае нужно установить «Время задержки перед запуском метода», равное 0 секунд. При обращении к приложению сразу будет произведена попытка сквозного входа по сеансу операционной системы.

Дополнительный сценарий. Пользователи не всегда имеют возможность войти в домен операционной системы, либо пользователям в некоторых случаях необходима возможность войти в приложения под другой учетной записью чем та, что они использовали для входа в домен. В этом случае нужно установить «Время задержки перед запуском метода» такое, чтобы пользователю хватило времени для возможности отменить автоматический вход с использованием сеанса операционной системы.

«Время ожидания получения токена» нужно установить достаточным, чтобы Kerberos сервер успевал предоставить ответ Blitz Identity Provider. Обычно достаточно установить 5 секунд.

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

Настройки браузеров пользователей#

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

Для браузеров под операционной системой Windows нужно задать следующие настройки:

открыть «Пуск → Панель управления», изменить вариант просмотра с «Категория» на «Мелкие значки», в открывшихся настройках выбрать «Свойства браузера»;
в новом окне выбрать «Безопасность → Местная интрасеть» и нажать кнопку «Сайты». В открывшемся окне нажать кнопку «Дополнительно» и внести сайт с Blitz Identity Provider в список сайтов «Местная интрасеть», нажав «Добавить»;
в окне «Свойства: Интернет → Безопасность → Местная интрасеть» нажать кнопку «Другой…». В открывшемся окне найти настройку «Проверка подлинности пользователя → Вход». Установить ее в значение «Автоматический вход в сеть только в зоне интрасети».

Можно не задавать для операционной системы Windows описанные выше настройки и в качестве альтернативы для возможности входа по сеансу операционной системы в браузере Google Chrome тогда можно запускать браузер со следующими параметрами запуска:

Chrome.exe –auth-server-whitelist="idp.domain.ru" –auth-negotiate-delegatewhitelist="idp.domain.ru"  –auth-schemes="digest,ntlm,negotiate"

Где в качестве idp.domain.ru нужно указать URL сайта Blitz Identity Provider.

Также можно задать следующие настройки в реестр Windows, чтобы запускать браузер Google Chrome без параметров запуска.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthNegotiateDelegateWhitelist"="idp.domain.ru"
"AuthSchemes"="basic,digest,ntlm,negotiate"
"AuthServerWhitelist"="idp.domain.ru"

Для Mozilla Firefox нужно задать следующие настройки (для любых операционных систем):

в адресной строке браузера ввести about:config и нажать «Enter». В следующем окне ввести network.nego в поле «Фильтры». Дважды нажать на найденной записи «network.negotiate-auth.trusted-uris» и установить в ней значение URL сайта с Blitz Identity Provider, например, idp.domain.ru. При указании адресов можно использовать звездочку (*) и указать несколько URL через запятую, например: https://*.idp.domain.ru,http://*.idp.domain.ru. Закрыть всплывающее окно кнопкой «ОК».
дважды нажать на найденной записи «network.negotiate-auth.delegation-uris» и установить в ней значение URL сайта с Blitz Identity Provider, например, idp.domain.ru. При указании адресов можно использовать звездочку (*) и указать несколько URL через запятую, например: https://*.idp.domain.ru,http://*.idp.domain.ru. Закрыть всплывающее окно кнопкой «ОК».
открыть параметр network.auth-sspi, установить его значение в true;
перезапустить браузер.

Для Google Chrome в macOS и в Linux нужно осуществлять запуск Google Chrome специальным образом:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --args --auth-server-whitelist="idp.domain.ru" --auth-negotiate-delegate-whitelist="idp.domain.ru"

Где в качестве idp.domain.ru нужно указать URL сайта Blitz Identity Provider.

Для Apple Safari в macOS отдельная настройка не требуется.

Настройки запуска приложений Blitz Identity Provider#

У пользователей могут возникнуть проблемы при входе по сеансу операционной системы, если они используют браузер Internet Explorer, и если в домене их учетная запись включена во многие группы безопасности, либо если DN учетной записи достаточно длинный. Чтобы избежать такой ситуации, необходимо при запуске приложения сервиса аутентификации blitz-idp задать специальный JAVA-параметр, определяющий большой допустимый размер HTTP-заголовка. Для этого необходимо отредактировать файл /etc/default/blitz-idp. В параметр JAVA_OPTS добавить ключ:

-Dakka.http.parsing.max-header-value-length=16K

Настройки веб-сервера#

У пользователей могут возникнуть проблемы при входе по сеансу операционной системы, если они используют браузер Internet Explorer, и если в домене их учетная запись включена во многие группы безопасности, либо если DN учетной записи достаточно длинный. Чтобы избежать такой ситуации, необходимо скорректировать настройки веб-сервера, определяющие допустимый размер буферов заголовков.

Рекомендуемые значения буферов для nginx приведены ниже:

proxy_buffer_size 16k;
proxy_buffers 4 16k;
proxy_busy_buffers_size 16k;
client_body_buffer_size 16K;
client_header_buffer_size 16k;
client_max_body_size 8m;
large_client_header_buffers 2 16k;

Отладка проблем с входом по сеансу операционной системы#

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

klist

Если команда успешно вернет TGS мандаты для SPN, настроенного для Blitz Identity Provider, значит нужно проверять корректность настроек на стороне браузера пользователя и в Blitz Identity Provider. Если TGS мандаты для Blitz Identity Provider отсутствуют, то можно их запросить, используя следующую команду (необходимо указать правильные SPN и имя домена компании):

klist get HTTP/idp.company.ru@DOMAIN.LOC

Если команда не вернет полученных TGS мандатов, значит нужно проверять корректность настроек на Kerberos-сервере.

Вход с помощью кодов подтверждения#

Можно использовать отправляемые в мобильное приложение push-уведомления или SMS-сообщения для проверки:

первого фактора аутентификации;
второго фактора аутентификации (см. Коды подтверждения, отправляемые в SMS и push-уведомлениях).

Для использования кодов подтверждения необходимо:

настроить и включить включить метод аутентификации «Подтверждение с помощью кода». Необходимо настроить:
- способ идентификации учетной записи – задать регулярное выражение. Например, правило phone_number=${login} означает, что введенное пользователем значение в форме входа будет сопоставлено с атрибутом phone_number;
- длину кода подтверждения;
- время действия кода подтверждения;
- количество попыток ввода кода подтверждения за 1 вход;
- общее количество попыток (число отправок кодов и попыток ввода кода, после чего для пользователя будет временно заблокирован данный способ аутентификации);
- время блокировки при превышении попыток (в минутах);
- сконфигурировать способы отправки кода:
  - отправлять push-уведомление – нужно указать атрибут с номером мобильного телефона или иным необходимым сервису идентификатором пользователя, например, ${phone_number};
  - отправлять SMS – указать атрибут с номером мобильного телефона пользователя, например, ${phone_number};
настроить подключение Blitz Identity Provider к SMS-шлюзу и сервису отправки push-уведомления.

Внимание

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

:size=55% — Настройки входа с помощью кода подтверждений#

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

При необходимости перейти к единым настройкам следует перейти по ссылке «Преобразовать в единый профиль» в блоке «Профили настройки метода».

Вход с известного устройства#

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

Настройка метода включает в себя указание длительности запоминания устройства. Также можно установить, что при входе с запомненного устройства не будет требоваться двухфакторная аутентификация (опция «Приравнять использование этого метода к применению первого и второго фактора»). Если эта опция включена, то вход с известного устройства будет означать, что пользователь прошел двухфакторную аутентификацию.

Вход по разовой ссылке#

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

Примечание

Подробно этот сценарий описан в «Руководстве по интеграции» в главе «Открытие веб-ресурсов из мобильного приложения в режиме сквозной аутентификации».

Настройка метода включает в себя указание времени действия ссылки, используемой для автоматического входа. Чтобы сработал автоматический вход, с момента выработки ссылки (после успешного окончания регистрации или восстановления пароля или получения параметра css мобильным приложением) до момента инициирования входа пользователя прошло не больше указанного в настройке времени, и что ссылка ранее не была использована.

Вход по QR-коду#

В Blitz Identity Provider предусмотрена возможность настроить вход в веб-приложение по QR-коду в качестве первого фактора аутентификации. Процесс входа устроен следующим образом:

Пользователь в браузере инициирует вход в веб-приложение. В Blitz Identity Provider отображается страница входа. На странице входа пользователь выбирает «Войти по QR коду».
Blitz Identity Provider отображает на странице входа пользователю QR-код и инструкцию. QR-код имеет ограниченный срок действия (пользователю показывается таймер со сроком действия QR-кода).
Пользователь запускает мобильное приложение компании, в которое встроена поддержка режима входа по QR-коду, и считывает с помощью этого приложения QR код.
Мобильное приложение показывает пользователю детальную информацию о входе, полученную от Blitz Identity Provider (имя приложения, в которое осуществляется вход, IP-адрес, браузер и имя операционной системы устройства, на котором осуществляется вход).
Пользователь в мобильном приложении принимает решение, разрешить или запретить вход.
В зависимости от решения пользователя на компьютере происходит успешный вход пользователя в приложение или запрос входа отклоняется.

Настройка метода включает в себя указание следующих параметров:

время действия QR-кода – в течение этого срока пользователь должен считать QR-код и принять решение по входу;
ссылка, которая будет закодирована в QR-коде – указывает, какое приложение или веб страницу нужно запустить в случае считывания QR-кода стандартным приложением «Камера». В качестве параметра в ссылку будет передан закодированный QR-код (ссылка будет иметь вид QR_URL?code=b0671081-cb73-4839-8bc1-8cf020457228);
ссылка на логотип (опционально) – данный логотип будет отображаться в центре QR кода.

Вход с помощью ключей безопасности (WebAuthn, Passkey, FIDO2)#

Можно использовать ключи безопасности (WebAuthn, Passkey, FIDO2) для входа в Blitz Identity Provider. Для взаимодействия с ключами безопасности используется спецификация WebAuthn. Поддерживаются следующие типы ключей:

Внешние ключи – представляют собой аппаратные устройства в виде USB-ключей или брелоков, подключаемые к ПК, планшету и телефону с помощью USB-порта, Bluetooth или NFC. Для использования ключей не требуется установка на устройство драйверов, плагинов – взаимодействие с ключами осуществляется через встроенные возможности браузеров.
Встроенные ключи – встроенные в устройстве и операционной системе механизмы аутентификации, поддерживающие WebAuthn:
- Windows Hello – можно входить с помощью ПИН-кода Windows, проверки отпечатка пальца или распознания лица;
- Touch ID или пароль на MacBook;
- Touch ID или Face ID на мобильном телефоне iOS или проверки отпечатка пальца или распознания лица в Android.

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

Разрешенные режимы аттестации – использование только режимов FULL и FULL_NO_ROOT повысит безопасность, но не позволит использовать для входа некоторые ключи, а также ПИН-код Windows, так как при регистрации таких ключей аттестационный объект приходит без подписи производителя чипсета или ключа или с использованием самоподписанного ключа. Использование режима SELF позволяет атакующему реализовать атаку «человек по середине» на подмену ключа в момент регистрации, в случае если устройство пользователя контролируется атакующим.
Показывать метод только пользователям, которые привязали к учетной записи ключ безопасности – если Blitz Identity Provider уже идентифицировал пользователя, то он уже знает, настроены ли для учетной записи пользователя ключи безопасности. Если ключи безопасности не настроены, то можно настроить, чтобы пользователю метод входа с помощью ключа безопасности не показывался.
Приравнять использование этого метода к применению первого и второго фактора – если опция включена, то вход по ключу безопасности будет означать, что пользователь прошел двухфакторную аутентификацию.
Правила соответствия – при входе по ключу безопасности пользователя просят ввести логин. Настройка правил соответствия позволяет указать правила поиска соответствия учетной записи введенному логину. Для найденной учетной записи будет запрошена проверка входа по ключу безопасности. Для создания правила используется строка подстановки: ${login} – это строка, введенная пользователем в поле «логин». В результате, например, правило email=${login} означает, что строка, введенная пользователем, будет сравниваться с атрибутом email в хранилище данных.
Правила выбора хранилища атрибутов – как и в случае входа по логину и паролю, по умолчанию поиск пользователей для аутентификации происходит во всех активных хранилищах. В блоке «Правила выбора хранилища атрибутов» можно настроить правила, при выполнении которых поиск пользователя будет осуществляться в определенном хранилище (см. Вход по логину и паролю).

Подтверждение входа разовым паролем на основе состояния (HOTP)#

Для проверки второго фактора аутентификации с использованием метода аутентификации «Разовый пароль на основе секрета (HOTP)» можно использовать любой аппаратный брелок, совместимый со стандартом RFC4226 «HOTP: An HMAC-Based One-Time Password Algorithm».

Для использования HOTP необходимо:

настроить и включить данный метод аутентификации;
загрузить в Blitz Identity Provider файл с описаниями HOTP-устройств. Файл с описаниями предоставляет поставщик HOTP-устройств. Для загрузки файла с описанием используется раздел меню «Устройства» в консоли управления Blitz Identity Provider;
привязать HOTP-устройство к учетной записи пользователя и выдать HOTP-устройство пользователю. Привязку можно выполнить двумя способами – либо администратор привязывает устройство по серийному номеру к учетной записи пользователя в консоли управления в меню «Пользователи», либо пользователь привязывает устройство к своей учетной записи самостоятельно с использованием веб-приложения «Личный кабинет».

Для настройки метода аутентификации «Разовый пароль на основе секрета (HOTP)» необходимо задать:

максимальное допустимое отклонение при проверке кода — количество последующих кодов (например, если пользователь случайно нажал кнопку генерирования нового пароля и не использовал его в процессе аутентификации), при котором аутентификация пройдет успешно. При этом при вводе пользователем правильного кода Blitz Identity Provider автоматически восстановит синхронизацию с устройством;
отклонение для синхронизации – если пользователь многократно будет нажимать на устройстве кнопку выработки кода и не будет использовать код для подтверждения входа, то устройство перестанет быть синхронизированным с сервером. В этом случае при очередном входе пользователя в Blitz Identity Provider ему на странице входа будет предложено пройти процедуру сверки устройства. Для этого пользователь введет три последовательно выработанных устройством кода подтверждения. Далее в соответствии с заданной настройкой «Отклонение для синхронизации» Blitz Identity Provider проверит, встречается ли введенная пользователем последовательность кодов, и восстановит синхронизацию с устройством в случае успеха;
общее количество попыток – число попыток ввода кода подтверждения, после которого данный способ подтверждения будет заблокирован;
время блокировки при превышении попыток (в минутах).

Подтверждение входа разовым паролем на основе времени (TOTP)#

Для проверки второго фактора аутентификации с использованием метода аутентификации «Разовый пароль на основе времени (TOTP)» можно использовать любые устройства и программы, совместимые со стандартом RFC6238 «TOTP: Time-Based One-Time Password Algorithm». В качестве таковых могут быть:

аппаратные брелоки (генераторы разовых паролей) на основе времени;
мобильные приложения.

Наиболее известные приложения для выработки TOTP-кодов: Google Authenticator, Twilio Authy, FreeOTP Authenticator, Microsoft Authenticator, Яндекс.Ключ.

В настройках метода аутентификации «Разовый пароль на основе времени (TOTP)» необходимо указать:

Допустимое отклонение при проверке кода (количество предыдущих / последующих кодов). По умолчанию оба значения равны 1: пользователь при входе может ввести как текущий код подтверждения, так и следующий или предыдущий (сгенерированный в соседних временных интервалах). Такая необходимость может возникнуть, например, для компенсации возможной незначительной рассинхронизации серверного времени и времени на TOTP-устройствах пользователей.
Общее количество попыток – число попыток ввода кода подтверждения, после которого данный способ подтверждения будет заблокирован.
Время блокировки при превышении попыток (в минутах).
Настройка отображения генераторов разовых паролей, которая включает в себя «Атрибут с именем пользователя» и «Название единой системы входа». Эти параметры будут отображаться в мобильном приложении после привязки учетной записи пользователя.
Ссылки на приложения-генераторы разовых паролей. Следует указать ссылки на приложения, которые рекомендуется использовать пользователям. Эти ссылки будут предложены пользователю в веб-приложении «Личный кабинет».

Привязка устройств к учетным записям пользователей#

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

Привязка аппаратных брелоков#

Для возможности использования аппаратных HOTP и TOTP устройств в качестве средств аутентификации администратор должен предварительно загрузить в консоли управления в меню «Устройства» файл с описаниями партии устройств, полученной от их поставщика. Файл содержит сведения о серийном номере устройства, векторе инициализации и ряд других настроек. Blitz Identity Provider поддерживает загрузку файлов распространенных форматов (специализированные XML-файлы, CSV-файлы) файлов с описаниями устройств от различных производителей устройств.

Для выполнения загрузки файла нужно задать имя для загружаемый генераторов (это может быть, например, имя устройства), формат данных, а также путь к файлу с описаниями устройств. По нажатии кнопки «Загрузить» Blitz Identity Provider сообщит, сколько записей устройств было загружено или отброшено (если их описание в файле было некорректно, либо запись об устройстве уже присутствуют в системе).

Пример загружаемого файла формата Aladdin/SafeNet XML для HOTP устройств с алгоритмом SHA-1 с минимальным набором параметров:

<?xml version="1.0" encoding="utf-8"?>
<Tokens>
  <Token serial="SN123">
    <Applications>
      <Application>
        <Seed>7bba106e428231c4d4e78361375d161c2d59b40b</Seed>
        <MovingFactor>0</MovingFactor>
      </Application>
    </Applications>
  </Token>
</Tokens>

Пояснения по значениям параметров в файле:

serial – серийный номер устройства.
Seed – ключ устройства в шестнадцатеричном (hex) формате.

Примечание

Если для эмуляции HOTP-устройства используется программный генератор одноразовых кодов, то обычно в программном генераторе в качестве секрета вводится строка в формате Base32. В этом случае значение из Seed нужно из hex перекодировать в Base32, и полученное значение использовать в программном генераторе.
MovingFactor – начальное значение генератора (обычно 0).

В разделе «Устройства» также можно выполнить поиск устройства по серийному номеру, посмотреть, было ли привязано и к какой учетной записи найденное устройство.

После загрузки файла следует:

перейти к учетной записи пользователя, которому необходимо привязать устройство (меню «Пользователи», см. Привязка устройств для проведения двухфакторной аутентификации по разовому паролю);
найти раздел «Генератор паролей на основе времени (TOTP)» или «Генератор паролей на основе секрета (HOTP)»;
выбрать «Другой тип»;
ввести серийный номер необходимого устройства и текущий разовый код подтверждения.

Привязка мобильного приложения#

Для привязки мобильного приложения следует:

перейти к учетной записи пользователя, которому необходимо привязать мобильное приложение (меню «Пользователи», см. Привязка устройств для проведения двухфакторной аутентификации по разовому паролю);
найти раздел «Генератор паролей на основе времени (TOTP)»;
выбрать «GoogleAuthenticator»;
при необходимости отредактировать название мобильного приложения;
с помощью мобильного приложения сфотографировать отображаемый QR-код или ввести в приложение строчку-секрет.

Также пользователь может самостоятельно привязать мобильное приложение, генерирующее TOTP-коды, в веб-приложении «Личный кабинет».

Коды подтверждения, отправляемые в SMS и push-уведомлениях#

Можно использовать отправляемые в мобильное приложение push-уведомления или SMS-сообщения для подтверждения входа (второго фактора аутентификации).

Для использования кодов подтверждения необходимо:

настроить и включить метод аутентификации «Подтверждение с помощью кода». Для корректной работы метода необходимо определить:
- длину кода подтверждения;
- время его действия;
- количество попыток ввода кода подтверждения за 1 вход;
- общее количество попыток (число отправок кодов и попыток ввода кода, после чего для пользователя будет временно заблокирован данный способ аутентификации);
- время блокировки при превышении попыток (в минутах);
- сконфигурировать способы отправки:
  - отправлять push-уведомление – нужно указать атрибут с номером мобильного телефона или иным необходимым сервису идентификатором пользователя, например, ${phone_number};
  - отправлять SMS – указать атрибут с номером мобильного телефона пользователя, например, ${phone_number};
настроить подключение Blitz Identity Provider к SMS-шлюзу и сервису отправки push-уведомления (см. Настройка уведомлений и отправки сообщений).

Внимание

По умолчанию используются единые настройки для кодов подтверждения, отправляемых для проверки первого и второго фактора (см. Вход с помощью кодов подтверждения). Для разделения настроек необходимо перейти по ссылке «Сконфигурировать профиль для каждого фактора» в блоке «Профили настройки метода». Тогда настройки будут разведены и можно будет переключаться между первым и вторым фактором.

Коды подтверждения, отправляемые по электронной почте#

Можно использовать отправляемые по электронной почте коды подтверждения для подтверждения входа (второго фактора аутентификации).

Для этого необходимо:

настроить и включить этот метод аутентификации. Для корректной работы метода необходимо определить:
- длину кода подтверждения;
- время его действия;
- количество попыток ввода кода подтверждения за 1 вход;
- общее количество попыток (число отправок кодов и попыток ввода кода, после чего для пользователя будет временно заблокирован данный способ аутентификации);
- время блокировки при превышении попыток (в минутах);
- сконфигурировать способ отправки: указать атрибут, в которых сохранен адрес электронной почты пользователя, например, ${email};
настроить подключение Blitz Identity Provider к SMTP-сервису (см. Настройка уведомлений и отправки сообщений).

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

Подтверждение входа с помощью Duo Mobile#

BlМожно использовать мобильное приложение Duo Mobile (компания Cisco) для подтверждения входа (второго фактора аутентификации).

Для этого необходимо выполнить настойки на стороне сервиса Duo Security:

зарегистрировать учетную запись на сайте Duo;
войти в панель администратора и перейти в раздел «Applications»;
нажать на «Protect an Application», среди приложений найти «Auth API». После этого нажать на «Protect this Application», чтобы получить свой интеграционный и секретный ключ, а также имя хоста.

После выполнения этих операций нужно провести настройки в консоли управления Blitz Identity Provider.

сконфигурировать метод аутентификации «Duo push-аутентификация». Необходимо указать:
- параметры учетной записи Duo (имя хоста, интеграционный и секретный ключ);
- параметры взаимодействия:
  - имя пользователя (задается с помощью строки подстановки) – это имя будет отображено в Duo Mobile в качестве имени учетной записи;
  - время действия кода активации (в секундах) – время, в течение которого действителен код привязки (QR-код);
- данные для отображения в приложении – информация, отображаемая пользователю в Duo Mobile в виде «ключ: значение». Здесь можно передать значение пользовательского атрибута или какое-то фиксированное значение. В качестве значения также можно указать строку ${app} – это позволит отобразить имя приложения, куда пользователь входит;
- ссылки на загрузку приложения Duo Mobile.
включить метод «Duo push-аутентификации» в разделе «Аутентификация».

:size=60% — Настройки Duo push-аутентификации#

Привязка приложения Duo Mobile к учетной записи пользователя возможна следующими способами:

пользователем самостоятельно через веб-приложение «Личный кабинет»;
администратором через консоль управления.

В веб-приложении «Личный кабинет» пользователь должен перейти в раздел «Безопасность / Подтверждение входа» и выполнить следующие шаги:

Выбрать способ подтверждения входа – «Подтверждение с помощью мобильного приложения Duo Mobile».
Установить на смартфон приложение Duo Mobile и отсканировать QR-код, а также нажать «Подтвердить».
После проверки этот метод аутентификации будет добавлен пользователю.

В консоли управления администратор должен:

Найти необходимого пользователя.
Перейти к блоку «Приложение Duo Mobile (QR-код)» и нажать на кнопку «Привязать Duo Mobile».
Попросить пользователя отсканировать QR-код с помощью мобильного приложения Duo Mobile.

На рисунках приведен пример внешнего вида страницы входа при подтверждении входа с помощью push-уведомления в приложении Duo Mobile.

:size=25% — Запрос push-аутентификации на смартфоне#

Повторное подтверждение при входе с известного устройства#

Blitz Identity Provider запоминает устройства, на которых пользователь в процессе входа подтверждал вход с помощью одного из поддерживаемых Blitz Identity Provider методов подтверждения входа.

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

:size=40% — Запрос, доверяет ли пользователь браузеру#

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

Подтверждение входа с помощью ключей безопасности (WebAuthn, Passkey, FIDO2, U2F)#

Можно использовать ключи безопасности (WebAuthn, Passkey, FIDO2, U2F) для подтверждения входа в Blitz Identity Provider. Для взаимодействия с ключами безопасности используется спецификация WebAuthn. Поддерживаются следующие типы ключей:

Внешние ключи – представляют собой аппаратные устройства в виде USB-ключей или брелоков, подключаемые к ПК, планшету и телефону с помощью USB-порта, Bluetooth или NFC. Для использования ключей не требуется установка на устройство драйверов, плагинов – взаимодействие с ключами осуществляется через встроенные возможности браузеров.
Встроенные ключи – встроенные в устройстве и операционной системе механизмы аутентификации, поддерживающие WebAuthn:
- Windows Hello – можно входить с помощью ПИН-кода Windows, проверки отпечатка пальца или распознавания лица;
- Touch ID или пароль на MacBook;
- Touch ID или Face ID на мобильном телефоне iOS или проверки отпечатка пальца или распознавания лица в Android.

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

Разрешенные режимы аттестации – использование только режимов FULL и FULL_NO_ROOT повысит безопасность, но не позволит использовать для входа некоторые ключи, а также ПИН-код Windows, так как при регистрации таких ключей аттестационный объект приходит без подписи производителя чипсета или ключа или с использованием самоподписанного ключа. Использование режима SELF позволяет атакующему реализовать атаку «человек по середине» на подмену ключа в момент регистрации, в случае если устройство пользователя контролируется атакующим.
Показывать метод только пользователям, которые привязали к учетной записи ключ безопасности – если ключи безопасности не настроены, то можно настроить, чтобы пользователю метод подтверждения входа с помощью ключа безопасности не показывался.

Подтверждение ответом на контрольный вопрос#

Blitz Identity Provider позволяет для подтверждения входа запросить пользователя ввести ответ на контрольный вопрос. Это может быть полезно в сценариях подтверждения при восстановлении забытого пароля. Для использования данного способа аутентификации нужно выполнить настройки в конфигурационном файле, а также сконфигурировать метод аутентификации в консоли управления.

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

Общее количество попыток – число попыток ввода ответа на контрольный вопрос, после которых данный способ подтверждения будет заблокирован.
Время блокировки при превышении попыток (в минутах).

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

Настройка внешнего метода аутентификации#

Blitz Identity Provider позволяет разработчикам при внедрении добавить поддержку своего собственного метода аутентификации. Для этого нужно разработать приложение, реализующее логику аутентификации, и подключить этого приложение к Blitz Identity Provider. В Blitz Identity Provider для этого конфигурируется метод аутентификации «Внешний метод аутентификации». Можно реализовать внешний метод аутентификации для работы как в качестве первого, так и в качестве второго фактора аутентификации.

Для настройки использования Blitz Identity Provider с внешним методом аутентификации необходимо:

Сконфигурировать новый «внешний» метод первого или второго фактора аутентификации, нажав на ссылку «Добавить внешний метод аутентификации». Указать параметры этого метода аутентификации:
- идентификатор метода – карточка с названием метода будет отображаться среди методов аутентификации, к методу с данным идентификатором можно будет обращаться из процедуры входа;
- URL внешнего сервиса;
- названия утверждений – перечень утверждений, которые внешний метод может установить пользователю;
- передаваемые cookie – перечень названий cookies, которые будут пробрасываться при вызове внешнего метода;
- передаваемые заголовки – перечень заголовков, которые будут пробрасываться при вызове внешнего метода;
- URL сервиса определения применимости – адрес опционального сервиса метода. Если указан, то данный URL будет вызываться перед вызовом основного сервиса, чтобы определить применимость данного метода аутентификации. Если URL не указан, то считается, что метод применим всегда;
- cookie безопасности – название cookie, в которой будет передаваться идентификатор сессии из внешнего метода.
- передаваемые утверждения – перечень утверждений, которые должны быть переданы внешнему методу (если параметр не задан, то внешнему методу будут переданы все доступные в сеансе входа утверждения);
- дополнительные параметры – задаются в формате JSON. Указанные параметры будут переданы внешнему методу. Это может быть полезно, чтобы иметь возможность конфигурировать настройки внешнего метода аутентификации через консоль управления Blitz Identity Provider.
- после сохранения включить метод – чекбокс, указывающий на то, что необходимо сразу включить метод аутентификации после сохранения настроек.
На стороне внешнего метода необходимо предусмотреть обработку запросов на аутентификацию и определение применимости согласно документу Руководство по интеграции.

Настройка процедуры имперсонификации#

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

Процесс выбора вспомогательных учетных записей настраивается на вкладке «Имперсонификация». Для этого разрабатывается на Java процедура имперсонификации. Можно сохранить текст процедуры имперсонификации, и после успешной ее компиляции можно включить процедуру с помощью переключателя «Включение/выключение процедуры».