Может ли SAML когда-либо стать действительно безгражданством? | Атхарва Дев | ноябрь 2025 г.

Нажмите Enter или нажмите, чтобы просмотреть изображение в полном размере

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

Но когда дело доходит до аутентификации SAML, эта мечта усложняется.

Давайте рассмотрим, почему SAML естественным образом вводит состояние, какие подходы люди используют для его обработки в средах высокой доступности (HA) и действительно ли возможно сделать SAML без сохранения состояния.

Идеал без гражданства

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

Преимущества очевидны:

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

Такие протоколы, как OpenID Connect (OIDC) с JWT, хорошо подходят для этой модели, поскольку сам токен содержит все необходимые утверждения и состояние.

Однако SAML — совсем другое дело.

Где SAML представляет государство?

SAML (язык разметки утверждений безопасности) основан на XML и управляется потоками.
Он основан на корреляции нескольких сообщений при перенаправлениях между поставщиком услуг (SP) и поставщиком удостоверений (IdP).

Когда SP инициирует вход в систему, он отправляет AuthnRequest к IdP и ждет Response.
Но во время этого обхода SP должен запомнить некоторую информацию, чтобы позже проверить входящий ответ.

Типичные данные, которые необходимо временно хранить, включают:

• Идентификатор запроса: чтобы гарантировать Response соответствует правильному AuthnRequest.
• RelayState: чтобы запомнить, куда перенаправить пользователя после аутентификации.
• Информация о привязке и контексте: если вы используете привязки POST и Redirect или пользовательские расширения.

Другими словами, ИП нуждается состояние для безопасного завершения рукопожатия.
Именно здесь идеал безгражданства начинает давать трещину.

Подход «закрепленной сессии»

Самое простое решение и, вероятно, самое распространенное на практике — использовать закрепленные сеансы в балансировщике нагрузки.

Таким образом, как только пользователь запускает поток SAML на одном узле, каждый последующий запрос в ходе этого потока направляется на тот же сервер.

Плюсы:

• Очень легко реализовать.
• Нет необходимости во внешнем хранилище данных.

Минусы:

• Не совсем без гражданства.
• Может привести к неравномерному распределению нагрузки.
• Отработка отказа становится сложной: если узел выходит из строя во время входа в систему, пользователь должен перезапустить поток.

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

4. Подход «общая база данных»

Следующим шагом является сохранение состояния SAML в общем хранилище данных, доступном для всех узлов, таких как Redis, SQL или распределенный кеш.

Каждый раз, когда SP отправляет AuthnRequestэто сохраняет RequestID и другие необходимые детали в этот общий магазин.
Когда пользователь возвращается с SAML Responseлюбой узел может получить данные и завершить проверку.

Что обычно хранится:

• RequestID
• RelayState (цель перенаправления)
• Временная метка или срок действия
• Дополнительный контекст сеанса

Плюсы:

• Хорошо работает в средах высокой доступности.
• Любой узел может обработать ответ.

Минусы:

• Все равно требуется внешняя система.
• Вводит задержку и зависимость от другого компонента.
• Строго говоря, не без сохранения состояния, поскольку SP все еще сохраняет временное состояние вне запроса.

Этот шаблон надежен и широко используется, но он не является «чисто без сохранения состояния».

5. Идея «Состояние SAML в файлах cookie»

Можем ли мы полностью отказаться от сохранения состояния, сохранив эти корреляционные данные SAML на стороне клиента?

Теоретически да:

• При отправке AuthnRequest поставщик услуг может встроить RequestID и RelayState в подписанном зашифрованном файле cookie.
• Когда IdP перенаправляет обратно, SP считывает этот файл cookie, проверяет подпись и сопоставляет ответ.

Это устраняет необходимость:

• Прикрепленные сеансы
• Общие базы данных
• Любые данные корреляции на стороне сервера

Проблемы:

• Безопасность: Вы должны зашифровать и подписать файл cookie, чтобы предотвратить несанкционированный доступ или утечку информации.
• Ограничения по размеру: Размер файлов cookie обычно ограничен несколькими килобайтами, что подходит для небольших RelayStateно не для больших контекстов.
• Срок действия и очистка: вам необходимо управлять коротким сроком жизни и очищать файлы cookie с истекшим сроком действия.
• Междоменные проблемы: некоторые потоки SAML пересекают домены верхнего уровня, где файлы cookie могут быть недоступны.

И все же этот подход может работайте с облегченными реализациями SAML, где данные о состоянии минимальны и вы можете жестко контролировать безопасность.

Это максимально близко к безгражданству с классическим SAML, но все же не идеально.

6. Заключение: безгражданство, но только в духе

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

Хотя вы можете минимизировать это состояние, используя зашифрованные файлы cookie или внешние кэши, чисто без гражданства SAML реализация остается скорее теоретическим идеалом, чем практической реальностью.

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