Устаревшие бэкенды никогда не были рассчитаны на современную идентичность
Многие приложения внутри предприятия — внутренние порталы, системы выставления счетов, операционные консоли, панели администрирования поставщиков, устаревшие бизнес-инструменты — были созданы до широкого распространения SAML или OIDC. Они, как правило, распознают пользователя не через современные токены, а через HTTP-заголовок, учётные данные Basic-Auth или сессионную cookie, которой уже доверяют.
Миграция этих приложений на современный SSO выглядит просто в теории: переписать путь аутентификации бэкенда, добавить поддержку SAML/OIDC и подключить приложение к центральному поставщику идентичности. На практике это почти никогда не происходит. Исходный код может быть устаревшим, приложение может принадлежать вендору, изменение может нарушить регулируемый рабочий процесс, или стоимость просто не оправдана для внутреннего инструмента, который работает.
Организации оказываются перед выбором из двух плохих вариантов: оставить устаревшие приложения за пределами современного периметра идентичности или создать отдельную хрупкую интеграцию для каждого из них. Итог — разрозненный пользовательский опыт, децентрализованный контроль доступа и логика идентичности, рассеянная по устаревшим моделям каждого бэкенда.
Правильный подход — разместить современный уровень доступа перед приложением. Пользователь сначала проходит центральную идентичность, MFA, условный доступ и проверки доверия устройству; аутентифицированная идентичность затем транслируется в форму, которую уже понимает бэкенд. Приложение получает современный SSO-опыт без каких-либо изменений кода.
Однако этот переход необходимо выполнять аккуратно. Если поддельные заголовки идентичности от пользователя пересылаются в бэкенд без удаления, любой может добавить собственный заголовок X-Auth-User в свой запрос и выдать себя за другого пользователя. Шлюз должен удалять ненадёжные входящие значения, внедрять только доверенную идентичность, которую он сам создаёт, и строго ограничивать это по маршруту.
Выход из системы, потеря сессии и состояние идентичности, инициируемое бэкендом, также должны проходить через тот же движок. В противном случае пользователь может казаться вышедшим из системы на портале, пока сессия бэкенда остаётся активной, или сессия бэкенда может прерваться незамеченной уровнем доступа.
Backend SSO — это не о принудительной переписке устаревших приложений, а о размещении современного контроля идентичности перед приложением и безопасной трансляции аутентифицированной идентичности пользователя в язык, который уже принимает бэкенд.
Наш подход
Один объект конфигурации на бэкенд, пять форм инъекций, скоординированных с остальным движком доступа.
Удалять каждое входящее значение, затем внедрять аутентифицированное
Каждое правило инъекции сначала удаляет любую входящую копию целевого заголовка, cookie или значения Authorization, затем внедряет версию, полученную из аутентифицированной сессии. Пользователь, отправивший собственный «X-Auth-User», не может выдать себя за другого — его заголовок удаляется до того, как шлюз добавляет доверенный.
Пять форм инъекций для устаревших паттернов
Пользовательские заголовки (X-Auth-User, X-Forwarded-User, любое имя, которое читает бэкенд), Authorization Basic для приложений, ожидающих пару username:password, Authorization Bearer для бэкендов с поддержкой токенов, объединение значения Cookie для приложений, читающих именованную cookie, и SAML-SP для бэкендов, ожидающих подписанное SAML-утверждение. У каждой инъекции своя конфигурация; один бэкенд может использовать несколько форм одновременно.
Условия на уровне инъекции ограничивают каждое правило нужными маршрутами
Каждое правило инъекции имеет собственное условное выражение — применять только на пути admin, только при наличии определённого атрибута сессии, только для одного тенанта. Один и тот же бэкенд может получать более богатую идентичность на привилегированных маршрутах и минимальное подмножество — на публичных.
Потеря сессии бэкенда и инициированный бэкендом выход из системы проходят обратно через шлюз
Когда бэкенд сообщает об исчезновении сессии пользователя (известная сигнатура ответа для каждого сервиса), или когда бэкенд сам выходит из системы, AAM обнаруживает сигнал, очищает сессию на стороне шлюза и перенаправляет согласно настроенной политике. Приоритет «logout-wins» гарантирует, что очистка всегда выполняется перед любой дальнейшей инъекцией.
Возможности
Пять форм инъекции, дисциплина вырезания входных значений, которая делает их безопасными, плюс две формы для Windows-инфраструктуры — вход по Kerberos спереди и прозрачно публикуемый NTLM сзади.
Инъекция заголовков — любое имя заголовка, которому доверяет бэкенд
Простейшая и наиболее распространённая форма. Настройте имя заголовка (X-Auth-User, X-Forwarded-User, REMOTE_USER, всё, что читает бэкенд) и умную переменную, создающую значение (имя пользователя, email, список групп, отображаемое имя). Заголовок удаляется из входящих запросов, затем повторно добавляется из аутентифицированной сессии перед тем, как запрос достигнет бэкенда.
Инъекция Authorization Basic для приложений, ожидающих username:password
Для устаревших приложений с аутентификацией через HTTP Basic шлюз внедряет Authorization: Basic
Инъекция Authorization Bearer для бэкендов с поддержкой токенов
Для бэкендов, уже работающих с Bearer-токенами (внутренние API, микросервисы, современные интранет-приложения), AAM внедряет Authorization: Bearer
Инъекция значения Cookie с безопасным слиянием в один заголовок
Приложениям, читающим идентичность из именованной cookie, предоставляется инъекция значения cookie. Шлюз объединяет внедряемую пару name=value в заголовок Cookie запроса без уничтожения других cookies — наиболее подверженная ошибкам из четырёх форм на основе заголовков, обрабатываемая явной логикой слияния, а не наивной перезаписью.
Инъекция SAML-SP — подписанное SAML-утверждение на каждый запрос
Для бэкендов, ожидающих подписанное SAML-утверждение на каждый запрос, шлюз создаёт SAML 2.0-утверждение из аутентифицированной сессии, подписывает его ключом подписи SAML AAM и пересылает в бэкенд через настроенный заголовок. Типично для интеграций федерации идентичности в государственном секторе и корпоративных SaaS-бэкендов. Пользователь входит с современным IdP; бэкенд получает свежее ограниченное SAML-утверждение на каждый запрос.
Дисциплина удаления входящих данных применяется ко всем внедряемым значениям
Каждая инъекция сопровождается удалением той же цели на входе. Пользователь, установивший X-Auth-User в собственном запросе, отправивший поддельную Cookie с изменённым значением идентичности или воспроизводящий заголовок Authorization из другого места, не сможет добиться, чтобы значение прошло через шлюз. Инъекция выполняется только после того, как удаление освободило слот.
Условия на уровне инъекции для области применения и приоритета
К каждому правилу инъекции может прилагаться условие — тот же язык выражений, что в политике условного доступа. Внедрять только на пути admin; внедрять только когда пользователь входит в определённую группу; внедрять привилегированный вариант только при наличии атрибута. Условия компилируются способом, безопасным для приоритета ACL, так что несколько правил на одном бэкенде корректно компонуются.
Защита «только для аутентифицированных» вокруг каждой инъекции
Все инъекции предоставляются за аутентифицированным состоянием — они выполняются только тогда, когда запрос несёт действительную сессию AAM. Пользователь, проникший в обход аутентификации через неправильно настроенный маршрут, не может случайно получить внедрённые учётные данные бэкенда; анонимный запрос всегда достигает бэкенда без инъекции.
Вход по Kerberos — пользователь Windows распознаётся без запроса пароля
Браузер в домене договаривается со шлюзом по SPNEGO, и пользователь входит под своей учётной записью Windows — без второго пароля и без отдельного портала. Дальше бэкенд получает личность через ту форму инъекции, которую он понимает, так что унаследованное приложение получает бесшумный единый вход без единой строки изменений. Делегирование личности на бэкенд от имени пользователя намеренно вне области: оно привязывает шлюз к доменной модели доверия, от которой большинство инфраструктур сейчас уходит, а формы инъекции закрывают ту же потребность с куда меньшим радиусом поражения.
NTLM публикуется прозрачно — унаследованный парк продолжает работать
Старые приложения Windows, согласующие NTLM, публикуются без изменений. Платформа распознаёт схему, помечает соединение как приватное — поэтому оно никогда не разделяется и не перебалансируется — и закрепляет его за сервером, выдавшим запрос; именно это позволяет NTLM пережить прокси. Никакого агента на сервере, никаких правок кода, никаких исключений в межсетевом экране.
Операционная глубина
Механизмы, обеспечивающие безопасность инъекций уровня заголовков на периметре доступа.
Компиляция безопасного для приоритета стека условий
Условия на уровне инъекции компонуются с другими решениями шлюза, основанными на ACL (состояние аутентификации, политика доступа, выбор бэкенда). Компилятор условий использует паттерн extra-entries, чтобы условия инъекций всегда оценивались после аутентификации и политики, но не до — правило на уровне инъекции не может случайно инвертировать результат решения политики с более высоким приоритетом.
Условное получение переменных frontend через диспетчер
Когда инъекции требуется значение, которого нет в контейнере сессии — значение, полученное через получение на запрос (расширение группы, поиск атрибута), — диспетчер генерирует условное получение, которое выполняется только при совпадении условия инъекции. Бэкенды, никогда не видящие инъекции, никогда не несут стоимость получения значения.
Обнаружение потери сессии бэкенда с настраиваемой сигнатурой ответа
Каждый сервис может объявить сигнатуру ответа, означающую «моя сессия пропала» — конкретный код состояния, конкретный заголовок ответа, маркер тела. Когда шлюз видит эту сигнатуру, он устанавливает флаг потери сессии, очищает сессию на стороне шлюза и выполняет перенаправление согласно настроенной политике.
Очистка при выходе из системы, инициированном бэкендом, и цепочка перенаправления
Когда бэкенд сам выходит из системы — как правило, отвечая известной сигнатурой выхода — шлюз выполняет трёхэтапную очистку: очищает cookies на стороне шлюза, удаляет запись сессии и перенаправляет через настроенную цель. Приоритет «logout-wins» гарантирует, что этот путь превосходит любую активную инъекцию.
Обработка зашифрованных значений, никогда не записываемых в логи в открытом виде
Учётные данные и токены, используемые инъекциями, хранятся зашифрованными в хранилище конфигурации и никогда не записываются в журналы доступа в открытом виде. Записи аудита фиксируют, что инъекция выполнялась для запроса, но не какое значение она несла. Операторы видят политику; полезная нагрузка провода остаётся на проводе.
Тихая повторная аутентификация при потере сессии сервера
Если сервер теряет свою сессию, пока сессия AAM ещё действительна, шлюз восстанавливает её в фоне — редиректом 302 к демону AAM, а не отправкой пользователя на страницу входа. Пользователь этого не видит. Выход работает и в обратную сторону: выход из шлюза передаёт сигнал завершения каждому серверу, получившему внедрённую личность.
Где команды применяют это
Современный SSO поверх существующего интранет-портала
Внутренний портал, доверявший X-Remote-User на протяжении десяти лет, продолжает читать X-Remote-User. Шлюз запускает современный SAML/OIDC на периметре, затем внедряет тот же заголовок, который портал всегда видел. Никакого нового развёртывания бэкенда, никакого перехода миграции.
Authorization Bearer перед микросервисами
Кластер внутренних микросервисов хочет аутентификацию Bearer-токена, но не хочет запускать поток идентичности для каждого сервиса. Шлюз выпускает подписанный токен на каждый запрос и внедряет его; каждый сервис проверяет токен по ключам шлюза.
Единый вход, множество форм аутентификации бэкенда
Мультиприложенческое развёртывание включает одно приложение, ожидающее Basic Auth, одно — пользовательский заголовок, и одно — cookie. Один шлюз AAM обрабатывает вход один раз; каждый бэкенд получает ожидаемую форму одновременно, с условиями на уровне маршрута.
Передача идентичности уровня аудита
Режимы соответствия, требующие чёткой цепочки идентичности — «кто был аутентифицирован при обработке этого запроса бэкендом» — получают эту цепочку из потока аудита шлюза. Значения заголовков, условия инъекций и аутентифицированный субъект записываются совместно.
Часто задаваемые вопросы
Как это работает без изменения кода бэкенда?
Что если пользователь отправляет собственный заголовок X-Auth-User, чтобы выдать себя за другого?
Может ли шлюз отправлять подписанное SAML-утверждение в бэкенд, ожидающий его для каждого запроса?
Что происходит при истечении сессии бэкенда, но действительной сессии AAM?
Может ли один шлюз AAM одновременно запускать разные формы инъекций для разных бэкендов?
Современный SSO на входе, устаревшая аутентификация на выходе
Мы развернём backend SSO против ваших реальных приложений — сохраняя их существующую модель доверия, убирая учётные данные из рук пользователя и создавая цепочку идентичности уровня аудита для каждого запроса.