Вы набрали в поиске «keycloak device trust» или «keycloak device posture». Выдача — issue #8742, пул-реквест про пропуск MFA и треды, где X.509, WebAuthn и «запомнить этот компьютер» свалены в одну кучу. Это разные вещи.
Текст для инженера, у которого Keycloak уже стоит: что IdP сегодня может доказать про машину, чего не может, и где обязан стоять агент. В конце есть продукт. В середине нет питча.
Что Keycloak умеет сказать про устройство сегодня
В каждом треде всплывают три механизма. Каждый отвечает на настоящий вопрос. Ни один не отвечает на «это рабочая станция, которую компания знает, в состоянии, которое компания принимает».
1. Cookie trusted-device
Нативного device posture в Keycloak нет. Ближайшая работа в дереве — pull request #48138, TrustedDeviceAuthenticatorна куке.
По согласию пользователя аутентификатор ставит cookie; на следующих входах этой куки достаточно, чтобы пропустить второй фактор. Нет аттестации железа, нет сигнала posture, нет агента, нет реестра устройств. При повторной проверке исходников в сентябре 2026 PR оставался открыт и не смержен. Он связан с issue #8742.
Текст issue однозначен. Пользовательская история: «As a user I want to only input two factor authenticator every 30 days.» Это меньше запросов MFA, а не device trust.
Кука «этот браузер здесь уже был» — не идентичность устройства. Кто украл куку — малварь, семейный ноут, сессия, которая пережила человека — получает пропуск. IdP не умеет спросить машину «ты всё ещё тот же компьютер, всё ещё с шифрованием диска, всё ещё не клон вчерашней ВМ».
Если нужна 30-дневная отсрочка MFA, кука — правильный инструмент. Если нужно «неизвестный ноут, верный пароль, отказ» — это другая категория.
2. X.509 и mTLS
Keycloak умеет требовать клиентский сертификат. Это настоящий контроль. И это другой продукт, не posture.
X.509 / mTLS доказывает, что клиент предъявил сертификат, которому IdP готов верить. Не доказывает шифрование диска, версию ОС, экранный замок и то, что машина есть в реестре компании. Чтобы выдавать и отзывать такие сертификаты, нужна CA, обычно SCEP или аналог, и процесс, который кладёт сертификат на ящик. Без этой инфраструктуры контроль мёртв. С ней вы по-прежнему знаете только «это тот сертификат».
Самообслуживание регистрации обычно и ломается. Подрядчик на личном Mac не хочет вашу CA в связке. Helpdesk, который рассылает P12, — это процесс, от которого вы как раз уходили.
3. WebAuthn
WebAuthn доказывает владение аутентификатором, привязанным к origin. Пасскей, ключ, платформенный аутентификатор. Это сильный ответ на фишинг человека. Это не ответ про рабочую станцию.
Аутентификатор может жить на YubiKey в сумке, в телефоне или в TPM ноутбука. Keycloak видит валидный assertion. Он не видит, открыл браузер корпоративный Mac, клонированная ВМ или чужая машина в кафе на пять минут. W3C несколько лет пытался протащить сведения об устройстве через WebAuthn (devicePubKey, потом supplementalPubKeys) и выкинул оба из Candidate Recommendation от 26 мая 2026. Платформа сама отказалась прятать posture в пасскей.
Пасскеи делают device trust нужнее, а не наоборот. Когда фишинг фактора исчез, остаточный риск — устройство и живая сессия.
Что такое posture
Posture — утверждение про машину в момент решения: идентичность ящика, несколько свойств безопасности, свежесть. Типичные вопросы:
- Этот серийник / аппаратный идентификатор есть в нашем реестре, в статусе, который мы принимаем (зачислен, не отозван)?
- Диск зашифрован? ОС не ниже пола? Экранный замок включён?
- Это утверждение подписано недавно ключом этой машины, а не проиграно с прошлой недели?
IdP может съесть вердикт. Собрать эти факты из вкладки браузера он не может. Браузер — отрисовщик. У него нет привилегированного взгляда на диск, прошивку и TPM, и не должно быть.
Расширение браузера вне ChromeOS не может получить ни одного аппаратно-подтверждённого факта об устройстве. Это не забытый permission в manifest.json. На Windows, macOS и Linux API enterprise.*, которые реально отдают данные устройства (deviceAttributes, platformKeys, networkingAttributes), — только ChromeOS. Единственный десктопный API, enterprise.hardwarePlatform, возвращает {manufacturer, model}.
Chrome умеет отдать настоящий posture — шифрование диска, secure boot, антивирус, патч-уровень — через chrome.enterprise.reportingPrivate. В текущем исходном коде Chromium этот API закрыт хардкод-allowlist из семи конкретных signing identities расширений. Обычная force-install policy сама по себе не добавляет новое расширение в этот список. Поэтому архитектура «posture одним произвольным расширением, без агента» вне ChromeOS не подтверждена доступным API.
Поэтому агент существует. Не потому что native messaging модно. Потому что это единственный канал, который видит машину.
Что агент реально отправляет
Агент TrustFlare ставится без MDM и без прав администратора. Собирает короткий инвентарь (модель, серийник, ОС, язык, часовой пояс) и подписывает ключом этой машины. Ядро проверяет подпись, реестр, свежесть и политику — и отвечает allow или deny.
Без MDM и без админ-прав: агент рассчитан на ноут, который вам не принадлежит — подрядчик, BYOD, дизайнер, который никогда не вступит в домен.
Пароли, сессии Keycloak и секреты IdP в облако TrustFlare не уходят. Уходит username при входе, IP, user-agent и подписанный инвентарь. Trial-ядро живёт 14 дней; данные удаляются через 30. Если данные не должны покидать периметр — это колонка Ultimate, не путь по умолчанию.
Мы не называем агент EDR. Он не читает файлы, почту и нажатия клавиш. Он не даёт службе ИБ шелл на личном ноуте. Видимость для решения о входе, не кишки частной жизни.
Как выглядит шаг аутентификатора
Пользователь вводит пароль в Keycloak как всегда. После пароля (Required) в потоке стоит шаг TrustFlare Device Trust.
Шаг ходит в ядро с одноразовым handle. Агент к этому моменту уже отправил подписанный payload. Allow — поток продолжается, сессия выдаётся как обычно. Deny — вход закрыт, в SIEM полное событие: кто, откуда, какое устройство, почему. В самих приложениях ничего не меняется. Никакого SDK в SPA, никакого прокси перед каждой админкой.
Первый раз новый ноут появляется в реестре и ждёт, пока его одобрит человек с уже доверенным устройством — обычно телефон владельца. Это петля в духе Duo: предохранитель в кармане, не в тикете.
Второй ноут без агента, тот же пароль, тот же TOTP — отказ. Это и есть весь продукт, его можно открыть на живом стенде.
Граница: сессию после входа мы не защищаем
TrustFlare принимает решение в момент аутентификации. Когда Keycloak уже выдал сессию, мы не сидим в запросах, не отзываем куку, если через час на ноуте выключили шифрование диска, и не рвём SSH, открытый утром.
Это не забытый чекбокс. Это форма аутентификатора IdP. Он работает, когда пользователь входит. Дальше сессия принадлежит Keycloak, VPN и приложению.
Что из этого не следует:
- Мы не EDR. EDR смотрит дерево процессов. Мы нет.
- Мы не замена step-up на чувствительном действии внутри приложения. Если нужно «перепроверить устройство перед этим переводом» — это другой крючок, и мы не притворяемся, что он у нас есть.
- Мы не Google DBSC. DBSC привязывает куку к устройству против инфостилеров, только Chrome на Windows, и спека прямо говорит, что гарантий о состоянии устройства нет. Другой слой.
Если главная угроза — украденный session token, нужны token binding, короткие TTL и то, что уже делают ваши приложения. Device trust на входе — дополнение: он останавливает следующий вход с неизвестного ящика с верным паролем. Он не откатывает вход, который уже случился.
Эту фразу лучше написать здесь, чем инженеру находить её в пятничном инциденте.
Куда дальше
Если карта совпала с задачей — Keycloak, смешанный парк, без rip-and-replace — короткий путь: quickstart: частное ядро, JAR в providers/, три переменные, trustflare-doctor и агент на одной машине. Пока публичный self-service недоступен, подключаем вручную по заявке.
Лестница цен — на /pricing/. Free до 100 пользователей. Пилот — платный, четыре недели на их стенде, не созвон со слайдом.
Если нужно только не вводить MFA 30 дней — берите куку. Эта задача уже названа, и это не она.