2.3.7 Аутентификация

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

../../_images/image101.png

Рис. 2.106 Вкладка «Домен.Аутентификация»

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

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

Редактирование параметров вкладок становится доступным после нажатия на кнопку «Изменить».

Ниже детально рассмотрены каждая вкладка по отдельности.

2.3.7.1 Связи потоков

Связи потоков аутентификации позволяют определить, какой поток следует использовать для определенного типа способа аутентификации.

Определены различные способы аутентификации:

  • «Поток браузерной аутентификации» – способ аутентификации пользователя посредством браузера;
  • «Поток регистрации» – соответствует событию регистрации пользователя;
  • «Поток аутентификации прямого доступа» соответствует аутентификации, выполненной из интерфейса командной строки с использованием REST API;
  • «Поток сброса учетных данных» – соответствует действию сброса учетных данных пользователя;
  • «Поток аутентификации клиентских систем» – соответствует аутентификации клиентских приложений в TVS.

Во вкладке «Связи потоков» можно изменять типы потоков аутентификации (Рис. 2.107).

../../_images/image102.png

Рис. 2.107 Аутентификация. Связи потоков

Доступен выбор значений:

«HTTP вызов», «Авторизация Docker», «Браузерная аутентификация», «Браузерная аутентификация с использованием Captcha», «Браузерная с ролью», «Первичный вход через провайдера», «Прямой доступ», «Регистрация», «Сброс учетных данных».

Выберите необходимый параметр и нажмите на кнопку «Сохранить».

2.3.7.2 Политика паролей

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

Перейдите на страницу:

Домены >> Имя домена >> Безопасность >> Аутентификация >> Политика паролей.

Данная вкладка предоставляет возможность задавать политики паролей для пользователей. Нажмите на кнопку «Создать». В всплывающем окне «Создание политики паролей» (Рис. 2.108) укажите значения параметров:

  • Тип политики – выбрать из раскрывающегося списка требуемый параметр;
  • Значение политики – определяется к количественном значении, если таковое значение можно задать.
../../_images/image103.png

Рис. 2.108 Аутентификация. Политики паролей

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

Набор полей и значение, которые нужно указать зависят от типа политики:

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

  • Алгоритм хэш функции - пароли не хранятся в виде открытого текста. Вместо этого вычисляется их хэш с использованием стандартных алгоритмов хеширования, прежде чем они будут сохранены или проверены. Можно использовать 3-и алгоритма шифрования: pbkdf2, pbkdf2-sha256 или pbkdf2-sha512. Следует отметить, что при изменении алгоритма, хэши паролей не будут изменены до следующего входа пользователя в систему;
  • Количество итераций хэш-функции – значение указывает, сколько раз хэш будет вычислен, прежде чем он будет сохранен или проверен. Значение по умолчанию - 27 500. Итеративность используется для большей защиты паролей от злоумышленников. Рекомендуемое в отрасли значение этого параметра меняется каждый год по мере увеличения мощности процессора. Более высокое значение итерации вычисления хэш-функции требует больше ресурсов процессора и может повлиять на производительность. Могут существовать более рентабельные способы защиты хранилищ паролей;
  • Минимальное количество цифр - минимальное количество цифр, необходимых в строке пароля;
  • Минимальное количество символов в нижнем регистре – минимальное количество строчных букв необходимых в строке пароля;
  • Минимальное количество символов в верхнем регистре – минимальное количество заглавных букв необходимых в строке пароля;
  • Минимальное количество спецсимволов – минимальное количество специальных символов необходимых в пароле, например, „?! #% $“;
  • Недопустимость имени пользователя в пароле – пароль не может совпадать с именем пользователя;
  • Регулярное выражение для проверки пароля – определяет шаблоны регулярных выражений (см. https://javarush.ru/groups/posts/regulyarnye-vyrazheniya-v-java), которым должны соответствовать пароли;
  • Принудительная смена пароля по истечении дней – количество дней, втечение которых действует пароль. По истечении указанного количества дней пользователь должен изменить свой пароль;
  • Количество смен паролей с недопустимой повторяемостью – политика сохраняет историю предыдущих паролей. Количество хранимых старых паролей можно настроить. Когда пользователь меняет свой пароль, он не может использовать какие-либо сохраненные пароли;
  • Минимальное количество различных символов в новом и старом паролях – новый пароль должен иметь отличия указанные в настройках данной политики.

Для удаления политики паролей кликните мышью на удаляемый тип политики. Отобразится кнопка «Удалить». Нажмите на кнопку для удаления политики. Подтвердите свои действия во всплывающем окне «Удаление политики паролей».

../../_images/image104.png

Рис. 2.109 Окно создания политики паролей.

../../_images/image105.png

Рис. 2.110 Окно удаления политики паролей

Примечание.

Максимальная длина пароля 30 символов.

2.3.7.3 Обязательные действия

Обязательные действия – это действия, которые пользователь должен выполнить в процессе аутентификации. Пользователь не сможет завершить процесс аутентификации, пока эти действия не будут выполнены. Например, администратор может запланировать сброс паролей пользователей каждый месяц. Для всех этих пользователей будет установлено действие, необходимое для обновления пароля.

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

Перейдите на страницу:

Имя домена >> Безопасность >> Аутентификация >> Обязательные действия.
../../_images/image106.png

Рис. 2.111 Окно вкладки «Обязательные действия»

На рисунке в списке обязательных действий отображены:

  • Настройка ТОТР;
  • Принятие условий и соглашений;
  • Обновление пароля;
  • Обновление профиля;
  • Подтверждение Email.

Каждое обязательное действие можно активировать и деактивировать. Кнопка активации/деактивации отображается при выделении строки с обязательным действием, требующим коррекции. Кнопка находится в столбце «Активность».

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

Каждому обязательному действию присвоен приоритет. Чем выше строка в списке – тем выше приоритет. С помощью фильтра в конце строки можно регулировать приоритет обязательного действия.

2.3.7.4 Политики одноразовых паролей (ОТР)

В системе существует ряд политик, которые можно настроить для генератора одноразовых паролей FreeOTP или Google Authenticator. Любая политика, которая определяется на данной вкладке, будет использоваться для проверки одноразовых паролей. На основе настроек формируется QR-код, штрих-код.

Есть два разных алгоритма генераторов одноразовых паролей. По времени (TOTP) и по счетчику (HOTP).

Для TOTP генератор токенов будет вычислять хэш по текущему времени и общий секретный ключ. Сервер проверяет OTP, сравнивая все хэши в течение определенного периода времени с отправленным значением. Таким образом, TOTP действительны только в течение короткого промежутка времени (обычно 30 секунд).

Для HOTP используется общий счетчик вместо текущего времени. Сервер увеличивает счетчик при каждом успешном входе в систему с помощью OTP. Таким образом, допустимые одноразовые пароли изменяются только после успешного входа в систему. TOTP считается немного более безопасным, потому что соответствующий OTP действителен только в течение короткого промежутка времени, в то время как OTP для HOTP может быть действительным в течение неопределенного времени. HOTP гораздо удобнее для пользователя, так как пользователю не нужно спешить с вводом одноразового пароля до истечения временного интервала.

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

Для создания политики одноразовых паролей перейдите на страницу:

Имя домена>> Безопасность>> Аутентификация>> Политики одноразовых паролей (TOTP) (Рис. 2.112).

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

../../_images/image107.png

Рис. 2.112 Окно вкладки «Политики одноразовых паролей»

Отредактируйте параметры.

Параметры конфигурации TOTP:

  • Алгоритм хеша OTP - по умолчанию - SHA1, более безопасные параметры - SHA256 и SHA512;
  • Количество цифр - короткое означает более удобное для пользователя, поскольку пользователю нужно меньше вводить символов. При большем количестве символов выше уровень безопасности;
  • Окно определяет количество интервалов через которое сервер должен попытаться сопоставить хэш - задается на тот случай, если часы генератора TOTP или сервера аутентификации не синхронизируются. Значение по умолчанию - 1, которого обычно достаточно. Например, если временной интервал для нового токена составляет каждые 30 секунд, значение по умолчанию 1 означает, что он будет принимать только действительные токены в этом 30-секундном окне. Каждое приращение этого значения конфигурации увеличивает допустимое окно на 30 секунд;
  • Период действия - интервал времени в секундах, в течение которого токен будет соответствовать хэшу. По истечении указанного периода времени, генератор токенов генерирует новый TOTP.

Параметры конфигурации HOTP:

  • Алгоритм хеша OTP - по умолчанию - SHA1, более безопасные параметры - SHA256 и SHA512;
  • Количество цифр - короткое означает более удобное для пользователя, поскольку пользователю нужно меньше вводить символов. При большем количестве символов выше уровень безопасности;
  • Окно определяет на сколько значений счетчика сервер должен попытаться сопоставить хэш - значение по умолчанию - 1. Задается на тот случай, если счетчик пользователя опережает счетчик сервера. Событие весьма вероятное, поскольку пользователи часто случайно увеличивают счетчик вручную слишком много раз. Значение может быть увеличено до 10;
  • Начальное значение счетчика задает стартовое значение счетчика.

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

2.3.7.5 Управление поведением аутентификации

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

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

../../_images/image108.png

Рис. 2.113 Окно вкладки «Управление поведением аутентификации»

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

../../_images/image109.png

Рис. 2.114 Окно вкладки «Управление поведением аутентификации», отображение типов управления поведением аутентификации

Доступны для управления следующие типы управления поведением аутентификации и информация по ним:

  • Браузерная аутентификация – аутентификация посредством браузера;
  • Браузерная аутентификация с использованием Captcha;
  • Прямой доступ – доступ к владельцу ресурса OpenID Connect;
  • Регистрация – регистрация пользователя;
  • Сброс учетных данных – сброс учетных данных;
  • Клиентские системы – базовая аутентификация клиентских систем;
  • Первичный вход через провайдера – управление поведением первичной аутентификации пользователя через провайдера идентификации;
  • Авторизация Docker – использовать клиентские системы Docker для повторной авторизации IDP;
  • НТТР вызов – управление поведением аутентификации посредством авторизации через HTTP запрос – ответ.

Для просмотра поведенческой ветви и изменений в ней нажмите на знак «i» - Изменить, расположенный в конце строки данной поведенческой ветви п. Раздел 2.3.7.5, откроется графическая структура поведенческой линии.

../../_images/image110.png

Рис. 2.115 Графическая структура поведенческой линии. Копия

Визуально цветами выделены типы поведения ветви:

  • Красный - отключена. Любая отключенная ветвь не оценивается и не считается успешно выполненной;
  • Зеленый - обязательна для выполнения. Поток считается выполнен успешно, если все обязательные элементы ветви выполнены без ошибок. Все обязательные элементы в потоке должны выполняться последовательно слева направо, в случае ошибки поток прерывает выполнение;
  • Желтый - альтернативная ветвь. Если поток содержит только альтернативные элементы, достаточно успешного выполнения только одного элемента, чтобы в целом поток был оценен как успешно завершенный. Наличии обязательного элемента в потоке достаточно, чтобы поток был успешно завершенным, любая альтернативная ветвь в этом потоке, которая содержит требуемые элементы потока, никогда не будет выполнена, т.е. нет смысла размещать в рамках одной ветви обязательные для выполнения и альтернативные элементы;
  • Синий - условное выполнение. Этот тип может быть установлен только для подпотоков. Условная ветвь может содержать условия ее выполнения. Эти условия должны оцениваться как логические операторы. Если все условные ветви выполнены успешно, тогда условный подпоток расценивается как «Обязательный для выполнения». В противном случае, условная ветвь соответствует типу поведению «Отключена». Если выполнение «Условий» не установлено, условный подпоток действует как «Отключено». Если поток содержит необходимые для выполнения условия и условие не проверялось, то выполнение условной ветви не оценивается и может считаться функционально отключенным.

2.3.7.5.1 Пример встроенного типа поведения (поведенческой ветви) аутентификации

На рисунке (Рис. 2.116) изображен встроенный тип поведения аутентификации – «Браузерная аутентификация».

../../_images/image111.png

Рис. 2.116 Пример встроенной поведенческой линии «Браузерная аутентификация»

Эта поведенческая ветвь состоит из нескольких типов поведения разного уровня. Первый уровень – 3 блока (узла) типа поведения, обрамленные рамкой желтого цвета, что означает – тип поведения – «Альтернативная ветвь»: «Cookie», «Перенаправление на провайдера идентификации», «Формы» и один блок, обрамленный рамкой красного цвета, что означает «Отключена» - «Kerberos».

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

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

Каждый узел может быть альтернативным или обязательным, или условно-обязательным (т.е. является обязательным при выполнении заданного условия).

В данном примере на первом уровне – три альтернативных узла и один – отключен; обход осуществляется слева направо.

Система пытается аутентифицироваться по «Сookie», при отказе переходит на «Kerberos», т.к узел отключен происходит переход на узел «Перенаправление на провайдера идентификации» далее на узел «Формы».

На втором уровне располагается узел «Форма ввода пароля и имени пользователя», которая обязательна для выполнения и обрамлена рамкой зеленого цвета.

Далее расположен узел «Браузерная аутентификация – Условная ОТР», в котором предусмотрена обязательная аутентификация для настроек пользователя, и, если настроено OTP, то поведение ввода кода OTP также становится обязательным.

../../_images/image112.png

Рис. 2.117 Дополнительная информация, всплывающая при нажатии на узел

2.3.7.5.2 Создание типа поведения (поведенческой ветви) аутентификации

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

Перейдите на страницу:

Домены >> Имя домена >> Безопасность >> Аутентификация >> Управление поведением аутентификации.

Нажмите на кнопку «Создать» в правом нижем углу окна. Во всплывшем окне «Создание поведенческой ветви аутентификации» укажите значения параметров:

  • Наименование – отображаемое наименование потока событий;
  • Провайдер (тип провайдера потока) – выберите из раскрывающегося списка предложенные варианты:
    • Клиентская система - для аутентификации клиентских систем. Подпоток (ветвь) может быть только данного типа;
    • Общий - для аутентификации пользователей. Можно разветвлять на «Общий», «Поток форм»;
    • Поток форм - для аутентификации через формы. Можно использовать только как ветвь в основном потоке с типом «Общий» или для ответвления типов «Общий», «Поток форм».
  • Описание (описание назначения потока событий) – опишите ветвь аутентификации (кратко).

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

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

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

Например, перенос первого слева на второй элемент от него справа позволит поставить его справа от выбранного элемента.

../../_images/image113.png

Рис. 2.118 Окно создания поведенческой ветви аутентификации

Произойдет переход на страницу с графическим отображением поведенческой ветви аутентификации.

../../_images/image114.png

Рис. 2.119 Графическое отображение поведенческой ветви аутентификации

Для создания поведения, во вновь созданной поведенческой ветви аутентификации нажмите на графический блок поведенческой ветви. В нижней панели управления отобразятся кнопки: «Удалить», «Создать поведение», «Создать ветвь», «Изменить», «Свернуть все».

Нажмите на кнопку «Создать поведение».

../../_images/image115.png

Рис. 2.120 Окно поведенческой ветви аутентификации

Кнопкой «Удалить» можно удалить одну из поведенческих ветвей. Выберите наименование поведенческой ветви. Нажмите напротив наименования кнопку «i». Произойдет переход в окно управления поведенческой ветвью (Рис. 2.121).

../../_images/image116.png

Рис. 2.121 Окно удаления поведенческой ветви аутентификации

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

2.3.7.5.3 Создание поведения

Перейдите на страницу:

Имя домена>> Безопасность>> Домены>> Аутентификация>> Управление поведением аутентификации.

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

../../_images/image117.png

Рис. 2.122 Окно создания способа выполнения аутентификации

Кликните левой кнопкой мыши по названию поведенческой ветви. Произойдет активация панели с кнопками управления внизу. Нажмите на кнопку «Создание поведения». В открывшемся окне «Создание способа выполнения аутентификации» заполните поле Провайдер.

Примечание.

Состав списка провайдеров для выбора зависит от параметра «Поток браузерной аутентификации» (задается на этапе настроек вкладки «Связи потоков» для конкретного домена).

При создании параметр «Тип поведения» всегда отключен. В дальнейшем при редактировании элемента значение можно заменить.

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

  • Автоматически настроить существующего пользователя – автоматически установить существующего пользователя в контекст аутентификации, без какой-либо проверки;

  • Базовая авторизация «запрос-ответ» – проверять подлинность запроса-ответа с использованием схемы HTTP BASIC;

  • Базовая авторизация по паролю и одноразовому паролю (OTP) – Аутентификация по запросу-ответу с использованием схемы HTTP BASIC. Пароль должен содержать комбинацию из пароля и одноразового пароля. Политика OTP домена используется для анализа.

    НЕ ДОЛЖНО ИСПОЛЬЗОВАТЬСЯ в сочетании с базовым провайдером;

  • Выбрать пользователя – выбрать пользователя для очистки учетных данных;

  • Неуспешная аутентификация – помечает поток аутентификации неуспешным;

  • Пароль – проверять пароль, указанный как параметр формы «пароль» в запросе на непосредственный доступ;

  • Переадресация – выполнить перенаправление с кодом HTTP 302, чтобы получить текущий URI пользователя по указанному пути в запросе аутентификации с параметром auth_session_id. Используется для клиентов, которые не поддерживают cookie. Идентификатор клиента и секретный ключ. Проверять клиента на основе «client_id» и «client_secret», содержащихся либо в параметрах запроса, либо в заголовке «Authorization: Basic»;

  • Перенаправление на внешний ресурс – перенаправить пользователя на внешний ресурс;

  • Перенаправление на провайдера идентификации – перенаправить на провайдера идентификации по умолчанию или провайдера идентификации указанного в параметре запроса kc_idp_hint;

  • Подтвердить ссылку на существующий аккаунт – показать форму, в которой пользователь подтверждает, хочет ли он связать поставщика с существующей учетной записью, или отредактировать данные профиля пользователя, полученные от поставщика, чтобы избежать конфликта;

  • Провайдер HTTP Basic – проверка имени пользователя и пароля с использованием заголовков HTTP;

  • Провайдер WebAuthn – провайдер для WebAuthn;

  • Проверить существование аккаунта по электронной почте – подтвердить по электронной почте существующего пользователя, который хочет связать свою учетную запись с поставщиком;

  • Проверка имени пользователя – проверять имя пользователя, указанное в качестве параметра формы «имя пользователя» в запросе на непосредственный доступ;

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

    Значение «on» означает, что страница для просмотра профиля будет отображаться, и пользователь может просматривать и обновлять свой профиль.

    Значение «off» означает, что страница не будет отображаться.

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

    Значение «Пропущено» является значением по умолчанию.

    ПРЕДУПРЕЖДЕНИЕ.

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

  • Сбросить пароль – обновлять пароль обязательно, если ТРЕБУЕТСЯ выполнение. Действие обязательно, если выполнение ОПЦИОНАЛЬНОЕ и в данный момент настроен пароль;

  • Сбросить электронную почту – очистить учетные данные пользователя с использованием электронной почты;

  • Сбросить OTP – устанавливать обязательное действие для конфигурации OTP;

  • Создать уникального пользователя – определить, существует ли учетная запись с тем же адресом электронной почты, что и у поставщика. Если нет, то создать нового пользователя;

  • Сookie - проверить SSO cookie, установленный сервером авторизации;

  • Условие - адрес пользователя – проверяет соответствие IP-адреса атрибуту пользователя;

  • Условие - настройки пользователя – выполнять только в случае, если настроены аутентификаторы;

  • Условие - проверка пулов адресов – проверяет пул адресов пользователя по белому и черному списку;

  • Условие - роль пользователя – выполнять только если пользователь имеет данную роль;

  • Успешная аутентификация – пометить поток аутентификации успешно выполненным.

  • Форма аутентификации с Captcha – проверять имя пользователя и пароль из формы входа, добавляет на форму кнопку Google Recaptcha; Проверка Recaptcha подтверждает, что объект аутентификации является человеком. Может быть использован только в системе с выходом в Интернет и требует настройки после добавления;

  • Форма ввода имени пользователя – определять пользователя по его имени;

  • Форма ввода пароля – подтверждать пароль на форме входа;

  • Форма ввода пароля для повторной аутентификации – подтвердить пароль из формы входа. Имя пользователя уже известно из аутентификации провайдера идентификации;

  • Форма ввода пароля и имени пользователя – проверять имя пользователя и пароль (на форме авторизации);

  • Kerberos - инициализация SPNEGO протокола. Чаще всего используется (Kerberos);

  • OTP - проверять одноразовый пароль, указанный как параметр формы «totp» в запросе на непосредственный доступ;

  • OTP форма - проверять OTP на отдельной форме OTP;

  • OTP форма (условная) - проверять OTP в отдельной форме OTP. Отображается только при необходимости на основании настроенных условий;

  • Идентификатор клиента и секретный ключ – проверять клиента на основе «client_id» и «сlient_secret», содержащихся либо в параметрах запроса, либо в заголовке «Authorization:Basic»;

  • Подпись JWt секретным ключом клиента - проверять клиента на основе подписанного JWT, изданного клиентом и подписанного с помощью Client Secret;

Нажмите на кнопку «Создать». Произойдет автоматическое перенаправление на страницу отображения ветви с поведением аутентификации. Отобразится созданное поведение.

Пример добавления условного поведения «Условие - адрес пользователя»

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

Пример использования данного поведения: создается данное поведение как условие, в подветви, и за ним создается поведение «Успешная аутентификация». Поведение имеет 2 атрибута:

  • Наименование атрибута пользователя – это атрибут, из которого берутся сведения о допустимых/недопустимых адресах;

    Само значение атрибута может быть таким: 192.168.0.100,10.10.5.0/23.

  • Тип фильтрации:

    • запрет – это значит, что условие поведения не выполнено,

    если адрес соответствует любому значению адресов/подсетей из атрибута, в противном случае выполнено;

    • разрешение – это значит, что условие поведения выполнено только в случае,

    если адрес соответствует любому значению адресов/подсетей из атрибута.

../../_images/image118.png

Рис. 2.123 Изменение конфигурационного параметра

Примечание.

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

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

2.3.7.5.4 Создание ветви

Перейдите на страницу:

Имя домена >> Безопасность >> Клиентские системы >> Управление поведением аутентификации.

Выберите наименование поведенческой ветви. Нажмите на кнопку «i». Будет выполнен переход в окно управления поведенческой ветвью.

Кликните мышью на название поведенческой ветви. Произойдет активация панели с кнопками управления (внизу). Нажмите на кнопку «Создать ветвь» (Рис. 2.124).

../../_images/image119.png

Рис. 2.124 Окно создания поведенческой ветви аутентификации

В открывшемся окне «Создание поведенческой ветви аутентификации» заполните поля:

  • «Тип поведения»;
  • «Наименование»;
  • «Провайдер»;
  • «Описание».

2.3.7.5.5 Изменение поведенческой ветви аутентификации

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

Нажмите на кнопку «Изменить», откроется окно «Изменение поведенческой ветви аутентификации» (Рис. 2.125).

../../_images/image120.png

Рис. 2.125 Поведенческая ветвь аутентификации. Изменение

Во всплывающем окне внесите требуемые изменения (Рис. 2.126).

../../_images/image121.png

Рис. 2.126 Окно изменения поведенческой ветви аутентификации

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

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

2.3.7.6 Пулы адресов

Во вкладке «Пулы адресов» находятся пулы IP-адресов для осуществления фильтрации.

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

../../_images/image6481.png

Рис. 2.127 Пулы адресов

Для создания пула адресов нажмите на кнопку «Создать», как показано на (Рис. 1.2). В появившемся окне заполните необходитые параметры (Рис. 2.223) и нажмите на кнопку «Создать».

../../_images/image6491.png

Рис. 2.128 Создание пула адресов

Для изменения пула выделите соответствующую строку кликом мыши, появится кнопка «Изменить» (Рис. 1.2) . Отредактируйте и сохраните требуемые параметры.

Для удаления пула выделите соответствующую строку кликом мыши, появится кнопка «Удалить» (Рис. 1.2). Подтвердите свои действия в появившемся диагностическом сообщении надатием на кнопки «Да/Нет».

2.3.7.7 Использование потоков аутентификации

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

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

Для решения этой задачи создайте поток следующего вида:

../../_images/image123.png

Рис. 2.129 Поток аутентификации «Проверка роли OIDC»

Где для провайдера «Перенаправление на внешний ресурс» задайте «URL перенаправления». Далее в провайдере аутентификации укажите созданный поток в поле «Поток после входа».

../../_images/image124.png

Рис. 2.130 Поток после входа

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

../../_images/image125.png

Рис. 2.131 Изменение способа аутентификации

В клиентских системах также можно указать потоки аутентификации:

  • Поток браузерной аутентификации - используется при аутентификации пользователей через веб-браузер;
  • Поток аутентификации прямого доступа - используется при аутентификации прямого доступа (через REST).
../../_images/image126.png

Рис. 2.132 Пример задания потоков аутентификации в клиентской системе