«id =» main «> Поделиться

В статье представлены избранные варианты конфигурации для двухфакторной аутентификации в двух системах единого входа: Apereo CAS и KeyCloak с использованием различных механизмов 2FA.

O Мы писали больше о решениях Apereo CAS и KeyCloak в нашем блоге. Мы рекомендуем статьи:

Apereo CAS против KeyCloak, какой сервер SSO стоит выбрать? Часть 1

и

Apereo CAS против KeyCloak, какой сервер единого входа выбрать? Часть 2

MFA/2FA

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

Оба этих решения SSO поддерживают стандарт 2FA, а Apereo CAS также поддерживает MFA. Система KeyCloak поддерживает Google Authenticator или FreeOTP. В CAS возможны конфигурации, поддерживающие механизмы Duo Secuirty, Authy Authenticator, Google Authenticator, YubiKey или Fido U2F. Полный список поддерживаемых поставщиков доступен по адресу:

Поддерживаемые поставщики

Политики OTP

2FA

Таким образом, двухфакторная аутентификация — довольно частый случай многофакторной аутентификации. & nbsp;

В следующем обзоре мы рассмотрим этот тип решения/аутентификации на примере реализации simple-mfa с использованием электронной почты в системе CAS и на примере реализации мобильных приложений для аутентификации в системе KeyCloak.

simple -mfa @cas

Поставщик simple-mfa предназначен для простых каналов связи, таких как электронная почта или текстовые сообщения. В этом решении CAS действует как поставщик многофакторной аутентификации, самостоятельно вырабатывая токены аутентификации и отправляя их конечным пользователям по предопределенным каналам связи.

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

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

dependencies {реализация «org.apereo. cas: cas-server-support-simple-mfa: $ {casServerVersion}»}

и настройки значения ключа свойства:

# Настройки MFA CAS cas.authn.mfa.provider-selection-enabled = true cas.authn.mfa.globalProviderId = mfa-simple # MFA Simple cas.authn.mfa.simple.name = mfa-simple cas.authn.mfa.simple.order = 1 cas.authn.mfa.simple.timeToKillInSeconds = 30 cas.authn.mfa.simple.tokenLength = 3

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

и введите сгенерированный токен на втором этапе:

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

Описанный токен аутентификации не сложен и имеет довольно простую форму. Он состоит из постоянной части «CASMFA-», которая не настраивается, и дополнительной случайной части длины, определенной в настройке cas.authn.mfa.simple.tokenLength.

Отправляемое электронное письмо пользователю полностью настраивается. Например, это может выглядеть так:

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

# Электронная почта MFA & nbsp; cas.authn.mfa.simple.mail.from=mfa@mockmock.jar  cas.authn.mfa.simple.mail.text = Ваш двухэтапный защитный код: & lt; h4 & gt;% s & lt;/h4 & gt; & nbsp; cas.authn.mfa.simple.mail.subject = Двухфакторный вход & nbsp; cas.authn.mfa.simple.mail.cc = & nbsp; cas.authn.mfa.simple.mail.bcc = & nbsp; cas.authn.mfa.simple.mail.replyTo = & nbsp; cas.authn.mfa.simple.mail.validateAddresses = false & nbsp; cas.authn.mfa.simple.mail.html = true & nbsp; cas.authn.mfa.simple.mail.attributeName = mail Доверенные устройства

С активацией двухфакторной аутентификации можно упростить конечным пользователям работу с приложениями, использующими систему CAS, путем добавления используемых устройств/браузеров в пул доверенных для данного пользователя. Это решение — если требуемый уровень безопасности, применяемый в организации, позволяет это, после первого правильного использования данного устройства во время двухфакторной аутентификации вам будет предложено добавить (и назвать) текущее устройство в доверенный пул:

Подобно добавлению simple-mfa в сборку, включение функциональности доверенных устройств сводится к включению модуля в Список зависимостей:

зависимости {& nbsp; реализация «org.apereo.cas: cas-server-support-trust-mfa: $ {casServerVersion}» & nbsp; } & nbsp;

и настройте ключи настройки:

# MFA Trusted Device/Browser & nbsp; cas.authn.mfa.trusted.authenticationContextAttribute = isFromTrustedMultifactorAuthentication & nbsp; cas.authn.mfa.trusted.deviceRegistrationEnabled = true & nbsp; cas.authn.mfa.trusted.expiration = 30 & nbsp; cas.authn.mfa.trusted.timeUnit = ДНЕЙ & nbsp; #

Просмотр и удаление активных и зарегистрированных устройств возможно через точку администрирования RESTAPI multifactorTrustedDevices.

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

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

app @keycloak

Реализация 2FA в системе KeyCloak основана на правилах OTP (одноразовый пароль), которые подробно описаны в документации по этому адресу. По умолчанию эти правила включены в базовую установку и не требуют установки дополнительных пакетов.

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

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

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

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

Конфигурация политики OTP

Конфигурация политики OTP по умолчанию является достаточной в большинстве случаев, а предопределенный выбор типа на основе времени (TOTP) считается более безопасным, чем HOTP. Тем не менее, TOTP требует & # 8222; синхронизации & # 8221; время между сервером Keycloaka и устройством конечного пользователя. Иногда это может вызвать проблемы с правильностью сгенерированного кода (error = expired_code). В этом случае отрегулируйте значение дополнительного временного окна [множитель] на вкладке политики OTP, доступной в разделе аутентификации.

Добавление пользователя устройства аутентификации

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

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

Код, введенный из генератора FreeOTP, позволит вам войти на сервер аутентификации и просмотреть информацию о пользователе. Необязательно введенное имя, идентифицирующее устройство/приложение аутентификации, упростит управление устройствами 2FA в будущем.

Резюме

Целью статьи было представить избранные варианты конфигурации двухфакторной аутентификации в двух системах SSO: Apereo CAS и KeyCloak с использованием различных механизмов 2FA.

Было проведено сравнение обеих систем. сделано и представлено в статьях, упомянутых в начале. И так, цитируя автора, выбор MFA/2FA зависит от потребностей и возможностей:

& # 8222; [& # 8230;] Итак, давайте рассмотрим все плюсы и минусы, прежде чем принимать окончательное решение . Все сводится к правильному определению наших потребностей. Ничто не мешает начать с небольшой производительности PoC. [& # 8230;] & # 8221;

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

Rate this post