Настройка обязательности 2FA для входа в приложения ПУИД

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

Общая схема

За проверку политик входа отвечает сервис roox-sso. Сервис читает правила из общего файла политик и применяет их к ресурсу входа в приложение:

/sso/<realm>/<clientId>/login

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

Значение amr	Описание
pwd	Пользователь прошел аутентификацию по логину и паролю
otp	Пользователь прошел второй фактор через OTP/TOTP

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

1. Портал самообслуживания разрешает вход после ввода пароля, без второго фактора, чтобы пользователь мог настроить TOTP.

2. Остальные прикладные клиенты требуют пароль и второй фактор otp.

3. При необходимости отдельная роль разрешает обход второго фактора для технически-обоснованных исключений.

Примечание

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

После изменения политик необходимо перезапустить сервис roox-sso командой:

sudo systemctl restart roox-sso

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

Типовые операции администратора

Включение обязательного второго фактора для приложения

Для включения обязательного второго фактора следует:

1. Определить client_id приложения, для которого нужно изменить правило входа.

2. В файле /usr/share/tomcat/policy.properties найти политику с ресурсом /sso/<realm>/<client_id>/login.

3. В условии allow-if оставить требование пароля и добавить требование второго фактора.

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

5. Перезапустить сервис roox-sso.

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

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

(token["claims"]["amr"]?.contains("pwd") ?: false ) and (token["claims"]["amr"].contains("otp") or (token["claims"]["roles"]?.contains("acp_iam_2fa_bypass") ?: false ))

Пример полной политики для нового приложения example_app в реалме employee:

com.rooxteam.sso.authz.policies.employee_example_app.enabled=true
com.rooxteam.sso.authz.policies.employee_example_app.actionName=GET
com.rooxteam.sso.authz.policies.employee_example_app.conditions.spelTokenCondition1.parameters.allow-if=(token["claims"]["amr"]?.contains("pwd") ?: false ) and (token["claims"]["amr"].contains("otp") or (token["claims"]["roles"]?.contains("acp_iam_2fa_bypass") ?: false ))
com.rooxteam.sso.authz.policies.employee_example_app.conditions.spelTokenCondition1.type=SpelTokenCondition
com.rooxteam.sso.authz.policies.employee_example_app.resourceName=/sso/employee/example_app/login

Отключение обязательного второго фактора для приложения

Для отключения обязательного второго фактора необходимо:

1. В файле /usr/share/tomcat/policy.properties найти политику приложения.

2. Убрать проверку otp из условия allow-if, но оставить остальные проверки доступа.

3. Не отключать всю политику через enabled=false, если задача состоит только в отключении 2FA.

4. Перезапустить сервис roox-sso.

5. Проверить возможность входа в приложение.

Пример условия, которое требует только пароль:

(token["claims"]["amr"]?.contains("pwd") ?: false )

Если приложение является административным, удаление проверки роли администратора не рекомендуется. Например, для административной панели может быть оставлено условие:

(token["claims"]["amr"]?.contains("pwd") ?: false ) and (token["claims"]["roles"]?.contains("acp_iam_admins") ?: false )

Настройка обхода 2FA для отдельной группы

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

1. Создать или выбрать группу в LDAP, членство в которой должно давать право входа без 2FA.

2. Удостовериться, что LDAP-атрибут с группами входит в profileAttributesToFetch и сопоставлен с полем roles в файле /usr/share/tomcat/ldap.properties.

3. Указать имя роли в выражении политики.

4. Перезапустить сервис roox-sso.

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

Примечание

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

Справочник путей к конфигурационным файлам

Назначение	Файл настройки на VM	Ответственный сервис или компонент	Действие после изменения
Политики доступа и политики входа в приложения	/usr/share/tomcat/policy.properties	roox-sso	Перезапуск roox-sso
Получение ролей пользователя из LDAP	/usr/share/tomcat/ldap.properties	roox-sso	Перезапуск roox-sso

Справочник параметров

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

Параметр	Значение по умолчанию	Пример	Описание
com.rooxteam.sso.authz.policies.<policy>.enabled	false	true	Включает политику. <policy> — имя политики, например employee_example_app. Допустимые значения: true, false
com.rooxteam.sso.authz.policies.<policy>.actionName	нет	GET	HTTP-метод или действие, к которому применяется политика. Для политики входа обычно используется GET
com.rooxteam.sso.authz.policies.<policy>.resourceName	нет	/sso/employee/example_app/login	Ресурс, к которому применяется политика. Для входа в приложение используется /sso/<realm>/<clientId>/login
com.rooxteam.sso.authz.policies.<policy>.conditions. spelTokenCondition1.type	нет	SpelTokenCondition	Тип условия политики. Для проверки claims-токена используется SpelTokenCondition
com.rooxteam.sso.authz.policies.<policy>.conditions. spelTokenCondition1.parameters.allow-if	нет	(token["claims"]["amr"]?. contains("pwd") ?: false )	Условие допуска пользователя. Для обязательного 2FA необходимо наличие pwd и otp в amr; для обхода — добавление проверки роли в roles
com.rooxteam.uidm.ldapv3repository.attributes.map	нет	login=uid,roles=memberOf	Сопоставление LDAP-атрибутов полям пользователя ПУИД. Для обхода 2FA поле roles должно получать группы или роли пользователя
``com.rooxteam.uidm.ldapv3repository.<alias>. profileAttributesToFetch``	пустой список	displayName,memberOf,mail,uid	LDAP-атрибуты, которые roox-sso получает при входе пользователя. Для нескольких LDAP-каталогов используется форма с <alias>; для одного каталога фрагмент <alias> может быть удален

Проверка после изменения

После внесения изменений необходимо убедиться, что вход в приложения ПУИД осуществляется следующим образом:

1. Пользователь без настроенного TOTP входит в кабинет самообслуживания по паролю.

2. Этот же пользователь не входит в приложения с обязательной 2FA до настройки TOTP, если у него нет роли обхода.

3. После настройки TOTP пользователь должен входить в приложения после прохождения OTP.

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

5. Пользователь без нужных прикладных ролей не должен получать доступ только из-за прохождения OTP.

Примечание

Если вход отклонен неожиданно, следует проверить журнал /var/log/roox-sso/roox-sso.log.

Особенности Платформы Astra Cloud

Для Платформы Astra Cloud используется реалм employee. В качестве второго фактора используется TOTP/ OTP: пользователь сначала входит по паролю в кабинет самообслуживания и настраивает второй фактор, после чего `roox-sso` запрашивает OTP при следующих входах и политики разрешают вход в остальные приложения.

Текущие политики входа

Фрагмент текущей конфигурации находится в файле /usr/share/tomcat/policy.properties, раздел LOGIN POLICY.

Политика	Ресурс	Правило
employee_selfservice_e	/sso/employee/selfservice_e/login	Достаточно pwd. Это исключение нужно, чтобы пользователь мог настроить TOTP
employee_arm_cc	/sso/employee/arm_cc/login	Нужны pwd, роль acp_iam_admins и одно из условий: otp или роль acp_iam_2fa_bypass
employee_aic	/sso/employee/aic-bm/login	Нужны pwd и одно из условий: otp или роль acp_iam_2fa_bypass
employee_amon	/sso/employee/amon/login	Нужны pwd и одно из условий: otp или роль acp_iam_2fa_bypass
employee_brest	/sso/employee/brest/login	Нужны pwd и одно из условий: otp или роль acp_iam_2fa_bypass
employee_apos_web	/sso/employee/apos_web/login	Нужны pwd и одно из условий: otp или роль acp_iam_2fa_bypass
employee_grafana	/sso/employee/grafana/login	Нужны pwd и одно из условий: otp или роль acp_iam_2fa_bypass

Группа обхода 2FA

Группа обхода задана в выражениях политик в файле /usr/share/tomcat/policy.properties через роль acp_iam_2fa_bypass:

(token["claims"]["roles"]?.contains("acp_iam_2fa_bypass") ?: false )

Итоговое правило для обычного приложения выглядит так:

com.rooxteam.sso.authz.policies.employee_aic.conditions.spelTokenCondition1.parameters.allow-if=(token["claims"]["amr"]?.contains("pwd") ?: false ) and  (token["claims"]["amr"].contains("otp") or (token["claims"]["roles"]?.contains("acp_iam_2fa_bypass") ?: false ))

Роль acp_iam_2fa_bypass должна попадать в роли пользователя. В текущей LDAP-конфигурации роли читаются из атрибута memberOf:

com.rooxteam.uidm.ldapv3repository.attributes.map=login=uid,displayName=displayName,contactEmail=mail,contactPhone=mobile,uid=ipaUniqueID,roles=memberOf,organization_id=street,rbtadp=rbtadp,rbtaou=rbtaou,givenname=givenName,sn=sn
com.rooxteam.uidm.ldapv3repository.ldap.domain.local.profileAttributesToFetch=displayName,memberOf,mail,telephoneNumber,mobile,ipaUniqueID,userPrincipalName,street,rbtadp,rbtaou,givenName,sn

Если в LDAP используется другое имя группы для обхода 2FA, необходимо изменить имя роли в выражениях политик или настроить сопоставление LDAP-группы с ролью acp_iam_2fa_bypass в фпйле /usr/share/tomcat/ldap.properties.