Александр Есин

Фанатам The Lord of the Rings

Вот такой суперский подарок получил от любимой супруги 😊👍

Теперь осталось только найти время собрать эту красоту. Результат выложу)

Полный текст поста — на сайте:
https://esin48.ru/blog/post.php?post=2026-10-27-fanatam-the-lord-of-the-rings
#личное

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

Прошлые посты были про то, откуда берутся данные о пользователе (федерация с AD, Kerberos) и как они попадают в токен. Теперь про второй фактор, потому что я про этот момент в прошлых постах забыл: где он хранится, как включается и почему иногда считается включённым, но не спрашивается.

Два слоя, которые постоянно путают

Двухфакторный вход в Keycloak — это две разные вещи:

- Сценарий входа (Authentication → Flows) — порядок действий: кого спрашивать, что требовать, при каких условиях
- Учётные данные пользователя (вкладка Credentials) — сам секрет: код в приложении, ключ безопасности, сертификат

Отсюда простое правило разбора: «второй фактор не спрашивают» — виноват сценарий. «Спрашивают, но не пускают» — виноваты данные или время.

Сценарий собирается из шагов. Шаги можно менять местами и помечать: обязательный, вариант на выбор, отключён. «Вариант на выбор» — значит подойдёт любой один. «Обязательный» — значит пройти нужно все по порядку. На этом и держится вся гибкость.

Что есть «из коробки»

- Одноразовые коды по времени или по счётчику — обычное приложение-аутентификатор. Самый частый вариант
- Ключи безопасности и встроенная биометрия (WebAuth)
- Вход по клиентскому сертификату
- Коды восстановления — резервный вход
- Принудительная настройка: при следующем входе система требует настроить код

Чего нет: кодов по SMS, push-уведомлений, кодов на почту. Это всегда отдельное расширение — а значит, внешняя зависимость и новый набор возможных проблем.

Настройки кодов: то, что потом долго и сложно менять

Для всего realm задаётся: тип кода, алгоритм, число цифр, период действия, окно допуска по времени, счётчик.

Что важно понимать:

- Окно допуска — сколько соседних интервалов принимается. Ноль — строго, но человек с отстающими часами будет страдать.
- Смена настроек ломает уже выданные секреты.
- Секрет для кодов хранится в базе Keycloak и попадает в выгрузку realm, но через веб он не виден.

Не всем и не всегда

Главная конструкция — условный второй фактор: отдельный шаг с проверкой.

Условия из коробки:

- Спрашивать, только если у человека уже настроен код
- Спрашивать, только если у человека есть определённая роль

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

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

Повышение требований под конкретную систему

Сценарий: обычный вход — только пароль, но при заходе в критичный сервис нужно подтверждение.

Работает так: система запрашивает нужный уровень защиты, Keycloak сверяет его с картой уровней и, если текущему входу не хватает, прогоняет дополнительный шаг.

Что нужно, чтобы заработало:

- карта уровней защиты заполнена в настройках realm
- сценарий умеет выдать нужный уровень
- система действительно запрашивает этот уровень

Ключи безопасности: надёжнее, но сложнее

Для них задаётся отдельно: домен, допустимые адреса, требования к проверке пользователя.

Три решения, которые принимают до внедрения:

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

Полный текст поста — на сайте:
https://esin48.ru/blog/post.php?post=2026-10-26-keycloak-2fa
#Keycloak #безопасность #полезное

Федерация в Keycloak с AD: как это устроено внутри

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

Две модели, которые постоянно путают

Прежде чем разбирать поток нужно развести два разных механизма:

- User Federation — AD выступает источником пользователей. Идентичность создаётся там, Keycloak её подтягивает: аутентификация идёт по паролю источника, атрибуты читаются оттуда.
- Identity Brokering — AD выступает внешним провайдером входа. Keycloak не видит пароль вообще, получает assertion/токен и на его основе заводит или связывает локального пользователя.

Разница принципиальная: в первом случае Keycloak знает секрет (или проверяет его через bind), во втором — доверяет подписи и заявлению. Все дальнейшие вопросы «почему нет атрибута» и «почему не обновилось» решаются в разных местах в зависимости от того, какой из двух механизмов у нас применяется.

Что происходит в момент логина (User Federation)

Пошагово:

1. Пользователь вводит логин. Keycloak ищет его в кэше провайдера.
2. Промах кэша → lookup в AD по настроенному атрибуту (username, sAMAccountName, UPN, mail — что выбрано при создании провайдера).
3. Найден → проверка пароля: bind сервисной учёткой, затем bind от имени пользователя. Пароль в Keycloak не сохраняется, он уходит в источник.
4. Успех → атрибуты прогоняются через mappers и складываются в локальную модель пользователя (в зависимости от Edit Mode).
5. Только теперь в игру вступают client scopes и protocol mappers из второго моего поста про Keycloak: они берут уже готовую модель и формируют токен.

Стадии 1–4 — это федерация, стадия 5 — выдача. Пустой claim почти всегда означает, что сломалась одна из первых четырёх, а не пятая.

Три режима, определяющие актуальность данных

- Imported — данные копируются в БД Keycloak при первом входе и живут там. Быстро, но между синхронизациями — устаревшие.
- Always read from source — атрибуты читаются при каждом обращении. Всегда свежие, но есть задержка при опросе самой AD, зависимость от доступности AD в момент логина — жёсткая.
- Write-back — изменения из Keycloak уезжают в AD. Требует прав на запись и аккуратности.

Выбор режима — это не техническая мелочь, а решение о том, где истина. Если отдел меняют в AD, а Keycloak держит копию — кто-то обязательно увидит старую должность в токене и придёт с вопросом.

Синхронизация: что и когда подтягивается

- Полная — обходит всех пользователей источника. Долго, нагружает каталог, нужна для первичного наполнения и после больших изменений.
- Инкрементальная — по метке изменения в источнике. Быстрее, но членство в группах и некоторые атрибуты подхватываются не так охотно, как хотелось бы.
- On-demand — при первом входе конкретного пользователя.
- Событийная — источник сам сообщает об изменениях. Самое свежее и самое хрупкое: ломается тихо.

Синхронизация обновляет модель пользователя. Она НЕ отзывает выданные токены. Старый access token живёт до истечения, refresh — до своего срока.

Маппинг: где чаще всего рассыпается цепочка

Данные идут в два прыжка:

1. Mapper федерации: атрибут AD → атрибут модели Keycloak
2. Protocol mapper в client scope: атрибут модели Keycloak → claim в токене
…

Полный текст поста — на сайте:
https://esin48.ru/blog/post.php?post=2026-10-25-keycloak-federation-ad
#полезное #безопасность #Keycloak

Client scope в Keycloak: что внутри, зачем нужен и как это работает поверх Active Directory

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

Scope чаще всего воспринимают как «галочку в настройках клиента». На деле это главный инструмент управления тем, что вообще попадает в токен. А когда под Keycloak стоит AD — почти все инциденты рождаются на стыке двух миров: федерации и scope. Разберём по порядку.

Что лежит внутри scope

Client scope — контейнер, который цепляется к клиенту и содержит:

- Protocol mappers — то, что реально формирует claims: audience, группы, роли, атрибуты пользователя
- Role scope mappings — какие роли (realm/client) попадут в токен при этом scope
- Тип: Default (применяется всегда) или Optional (только если клиент запросил через scope=)

Плюс встроенные: profile, email, roles, web-origins, address, phone, offlineaccess, acr, microprofile-jwt.

Важно: scope живёт на уровне realm и переиспользуется между клиентами. Это общий контракт, а не приватная настройка одного клиента.

Зачем он нужен

- Ограничить привелегии. Бухгалтерии нужен email, а не членство в 40 группах и не LDAP-пути.
- Переиспользование. Один scope «api-audience» на двадцать клиентов вместо двадцати одинаковых мапперов.
- Размер токена. Тяжёлые claims выносим в Optional — платим только там, где нужно.
- Явный контракт. Default = «клиент получает всегда», Optional = «можно запросить».

Главное, что нужно понять про AD

Scope НЕ знает про Active Directory. Он работает уже с загруженной моделью пользователя в Keycloak.

Данные проходят четыре звена:

1. AD → атрибут (sAMAccountName, mail, department, memberOf)
2. User Federation → LDAP mapper → попадает в модель пользователя Keycloak
3. Protocol mapper ВНУТРИ client scope → кладёт значение в токен как claim
4. Resource server читает claim

Отсюда правило, которое снимает половину вопросов: если атрибута нет в модели пользователя, можно поставить хоть десять protocol mappers — claim будет пустой. И наоборот: если атрибут в модели есть, но protocol mapper не привязан к нужному scope — в токене его не будет.

LDAP mapper — это «втянуть из AD в Keycloak». Protocol mapper в scope — это «отдать наружу в токене». Постоянно путают.

LDAP mappers, которые обычно настраивают

- Username / RDN mapper — username = sAMAccountName или userPrincipalName (выбор фиксируется при создании провайдера, потом не меняется)
- First name / Last name / Full name
- Email
- user-attribute-ldap-mapper — любой атрибут: department, title, employeeID, manager
- group-ldap-mapper — AD-группы → группы Keycloak
- role-ldap-mapper — AD-группы → роли Keycloak
- msad-user-account-control-mapper — учитывает userAccountControl (отключённые/заблокированные аккаунты)
- hardcoded-attribute-ldap-mapper — константа, если нужно

Имя атрибута в LDAP mapper и User Attribute в protocol mapper должны совпадать посимвольно. Разница в регистре — самая обидная причина пустого claim.

Edit Mode — рычаг против устаревших данных

- READONLY — атрибут импортируется и живёт в БД Keycloak. Изменилось в AD → в Keycloak старое, пока не прошла синхронизация …

Полный текст поста — на сайте:
https://esin48.ru/blog/post.php?post=2026-10-24-keycloak-client-scope
#безопасность #Keycloak #полезное