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

Фанатам 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 #полезное

Зомби, которых мы заслужили :-)

Посмотрел новую «Обитель зла». Смотрел, честно говоря, со скепсисом: сколько можно поднимать эту франшизу из мёртвых? Шесть фильмов с Йовович, перезапуск, сериал... Сама франшиза живее всех своих зомби, вместе взятых 😁

И вот сюрприз — на этот раз получилось.

Креггер, в отличие от Андерсона, не стал зацикливаться на играх RE, а создал свой оригинальный сценарий, в который крайне удачно ввёл «вселенную Обители зла». Другие герои, другой вирус — по сути, авторское кино по мотивам. Кто ждал пересказ знакомого сюжета — тот будет ворчать. Я поворчал минут десять, потом втянулся и забыл)

Причём сначала мне вообще казалось, что я смотрю какую-то чёрную комедию — страшно и смешно ровно там, где надо. Критики пишут, что это самый высокооценённый фильм по играм в истории — больше 90% на Rotten Tomatoes.

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

Единственное — концовка разочаровала. Без спойлеров, но очень хотелось, чтобы главный герой всё-таки спасся. Досадно, когда за два часа успеваешь к персонажу прикипеть, а финал решают за тебя.

А я ведь ещё помню первую игру: тёмный особняк, три патрона, шаги за дверью — и страшно нажать «вперёд». Того самого ощущения тут нет. Но есть другое, своё — и оно работает.

Моё резюме: рекомендую к просмотру. Только обратите внимание на русскую озвучку — их несколько, и они разные. Выбирайте внимательно)

Полный текст поста — на сайте:
https://esin48.ru/blog/post.php?post=2026-10-22-zombi-kotorye-my-zasluzhili
#личное #кино

Посылка, паспорт и доверенность: чем аутентификация отличается от авторизации и кто такие IdP

Эти два слова путают постоянно: в разговорах, в ТЗ и даже в документации. Звучат похоже, оба про «пустить или не пустить», только означают разное. Если их смешать, получаются дыры в безопасности и долгие споры с разработчиками.

Объясню на примере, который знаком каждому.

Почта

Вы пришли на почту за посылкой. Отстояли очередь (куда без неё) и называете оператору трек-номер или фамилию. Это идентификация: вы сказали, кто вы.

Оператор вам на слово не верит и просит паспорт. Сверяет фото с лицом, а ФИО с данными на посылке. Так она убеждается, что вы действительно тот, за кого себя выдаёте. Это аутентификация.

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

Если у вас есть доверенность от соседа, посылку отдадут. Права у вас не появились сами по себе: их вам передал владелец. Запомните этот момент, он ещё понадобится.

Если коротко:

- Идентификация — «Я Иванов».
- Аутентификация — «Докажи, что ты Иванов».
- Авторизация — «Что Иванову можно».

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

Как это выглядит в IT

Логин в форме входа — это идентификация. Пароль, код из SMS, отпечаток пальца — аутентификация. Система проверила их и узнала пользователя.

Потом он открывает раздел «Бухгалтерия» и получает «Доступ запрещён». Тут сработала авторизация: человека узнали, но прав у него нет. Ровно как с соседской посылкой.

Забавно, что даже в HTTP с этим путаница. Код 401 Unauthorized на самом деле означает «я не знаю, кто ты» (то есть «не аутентифицирован»). А «знаю, кто ты, но нельзя» передаёт код 403 Forbidden. Так исторически сложилось, и теперь с этим живём все).

Ещё одна частая ошибка: считать, что раз человек вошёл, то ему можно всё. Многие уязвимости в веб-приложениях появляются именно так. Пользователь меняет в адресной строке id=15 на id=16 и видит чужой заказ. Это как если бы оператор, проверив паспорт, разрешил вам самому взять с полки любую коробку. Аутентификация есть, а авторизацию никто не сделал.

Откуда берутся IdP

Обратите внимание на одну деталь: почта сама не устанавливает, кто вы. Паспорт выдаёт не почта, а МВД. Почта просто доверяет документу, который выдал кто-то другой, и умеет отличить настоящий от подделки. Банк, нотариус и поликлиника доверяют тому же самому паспорту.

В IT долго было не так. Каждый сервис заводил собственную базу пользователей, то есть выдавал свой «паспорт». Почта, облако, Git, мессенджер, фотоархив, Wi-Fi в офисе. В итоге:

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

Для этого придумали IdP (Identity Provider), то есть поставщика удостоверений. Это отдельный сервис, единственная задача которого — узнавать пользователей и выдавать им «паспорт», которому доверяют остальные. Тот самый паспортный стол.

Вы с этим наверняка сталкивались: кнопки «Войти через Google», «Войти через Яндекс ID», «Войти через Госуслуги». Сайт не знает и не хранит ваш пароль, он просто доверяет тому, кто вас проверил.

Материал большой, в пост не влез, читайте полностью в моем блоге:

https://esin48.ru/blog/post.php?post=2026-10-21-posylka-pasport-doverennost
#безопасность #полезное

Занавес

Решил начать делиться интересными историями из жизни. Историями с юмором. Вот первая.

В совсем юные годы я работал звукооператором в ДК. Навскидку — 2006-й. Обязанностей было «до кучи»: в том числе — принимать механику сцены перед представлением.

Пришли мы с осветителем задолго до начала. Он проверял свет, я — звук и подзвучку: в тот вечер шёл спектакль. Накануне у меня был выходной, и в тот день в зале поработал электрик.

Я, как обычно, пошёл в техническое помещение и начал прогонять механику с пульта: задник, кулисы и прочее. Последним шёл занавес. Нажал на открытие — из-за кулис раздался страшный треск, затем тяжёлый удар.

Как выяснилось, электрик перепутал фазы (там всё на 380). Огромный тяжёлый бархатный занавес вместо того, чтобы открыться, закрылся с ещё большей силой. Тросы не выдержали, и пока я бил по аварийному стопу, вся конструкция с грохотом рухнула на сцену — ровно перед оркестровой ямой.

Решить это за час до начала, разумеется, мы не успели. Выкрутились: сделали максимальное затемнение и сцены, и зала.

Мораль: никогда не пускай в своё хозяйство людей в своё отсутствие.

https://esin48.ru/blog/post.php?post=2026-10-20-zanaves
#личное #байки

Папин чемпион

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

Без имён, но картина типичная. Человек гордится достижениями сына в плавании. Только по всему видно, что сын этим плаванием заниматься не хочет. А отец — или мать — просто доигрывает свою несбывшуюся амбицию. Ребёнок за это платит. Насколько честны такие отношения с детьми?

Получается, родители за счёт детей компенсируют собственные недостатки и недоделки юности. Они мечтают, чтобы ребёнок сразу был суперзвездой везде, где не удалось им самим. А дети, возможно, просто не хотели. Им это неинтересно. У них может быть своё направление — другое, их. Таким подходом мы ломаем психику. Не отдельным детям, а всем подряд.

Медаль сына — самая доступная форма гордости: её можно потрогать, показать, положить в витрину. Гордиться тем, что человек сам нашёл своё, — сложнее: там нечего показать, кроме спокойного взрослого. Первое продаётся, второе только растёт.

https://esin48.ru/blog/post.php?post=2026-10-14-papin-chempion
#личное

Пугающие цифры :-)

Зашел тут в ВК и обнаружил это)

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

И, вообще, верните стену 😁 Срочно верните, и уберите эти ваши "граффити".

https://esin48.ru/blog/post.php?post=2026-10-10-pugayushchie-tsifry
#личное #Интернет #соцсети

Immich - альтернатива Google Photos

Фото на телефоне заканчиваются одинаково: память кончается, облако просит подписку, а «просто посмотреть семейный архив» превращается в передачу личных данных третьей стороне. Immich — self-hosted система хранения и каталогизации фото и видео. Ваше оборудование, ваш сервер, ваши правила. По ощущению — та же облачная галерея, только поиск по лицам и сценам считается дома, а не на чужой машине.

Ветка на момент написания — 3.x. Ставил 3.2.4 поверх 3.1.

Как это устроено

Immich — не один контейнер, а четыре. Лучше знать это до первой поломки:

- immich-server — веб-интерфейс, API, вся логика;
- immich-machine-learning — нейросети: распознавание лиц, семантический поиск, текст на снимках;
- database — PostgreSQL с расширением под векторный поиск;
- redis — очередь задач. Миниатюры, транскодинг видео и скан библиотек уходят в очередь и не считаются в момент вашего запроса.

Порт по умолчанию — 2283. Состояние живёт в двух местах: каталог хранилища (library, upload, thumbs, encoded-video, backups, profile) и каталог данных базы. Удалить одно без другого — получить базу без файлов или файлы без базы.

Установка

Каталог проекта и два файла. Все пути в примерах условные — подставьте свои.

.env:

``
UPLOADLOCATION=/srv/immich/storage
DBDATALOCATION=/srv/immich/db
DBHOSTNAME=database
DBPORT=5432
DBUSERNAME=immich
DBDATABASENAME=immich
DBPASSWORD=
REDISHOSTNAME=redis
REDISPORT=6379
TZ=Europe/Moscow
`

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

docker-compose.yml — сокращённо, показаны сервер и машинное обучение с монтированиями (полный шаблон берётся из официальной документации):

`yaml
services:
immich-server:
containername: immichserver
image: ghcr.io/immich-app/immich-server:${IMMICHVERSION:-release}
ports:
- "2283:2283"
volumes:
- ${UPLOADLOCATION}:/data
- /srv/photos/existing-archive:/mnt/archive:ro
envfile: .env
dependson:
database:
condition: servicehealthy
redis:
condition: servicehealthy

immich-machine-learning:
containername: immichmachinelearning
image: ghcr.io/immich-app/immich-machine-learning:${IMMICHVERSION:-release}
volumes:
- ${UPLOADLOCATION}:/usr/src/app/upload
- /srv/photos/existing-archive:/mnt/archive:ro
envfile: .env

redis:
containername: immichredis
image: docker.io/redis:6.2-alpine
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 10
restart: always

database:
containername: immichpostgres
image: ghcr.io/immich-app/postgres:14-vectorchord0.3.0-pgvectors0.2.0
environment:
POSTGRESPASSWORD:
POSTGRESUSER: ${DBUSERNAME}
POSTGRESDB: ${DBDATABASENAME}
volumes:
- ${DBDATALOCATION}:/var/lib/postgresql/data
envfile: .env
healthcheck:
test: ["CMD-SHELL", "pgisready -U $${POSTGRESUSER} -d $${POSTGRESDB}"]
interval: 5s
timeout: 3s
retries: 30
restart: always
`

Обратите внимание на :ro во втором монтировании — об этом ниже.

Запуск:

`bash
docker compose pull
docker compose up -d
`

Первый заход на http://<адрес-сервера>:2283 — мастер попросит создать аккаунт администратора.
…

https://esin48.ru/blog/post.php?post=2026-10-02-immich-alternativa-google-photos
#полезное