HTTP POST Binding

HTTP POST Binding — это один из стандартных методов передачи сообщений в протоколе SAML (Security Assertion Markup Language), предназначенный для безопасной передачи данных аутентификации и авторизации между системами через HTTP-запросы типа POST. Данный механизм обеспечивает доставку XML-документов, содержащих утверждения (assertions) о пользователе, от поставщика удостоверений (Identity Provider, IdP) к поставщику услуг (Service Provider, SP) или в обратном направлении.

Принцип работы

HTTP POST Binding использует стандартный HTTP-метод POST для передачи SAML-сообщений в теле запроса. В отличие от HTTP Redirect Binding, где данные передаются через URL-параметры (что накладывает ограничения на размер), POST Binding позволяет передавать сообщения практически неограниченного объёма, что критично для сложных XML-структур с цифровыми подписями.

Процесс передачи включает следующие этапы:

1. Отправитель (например, IdP) формирует SAML-сообщение (обычно <Response> или <AuthnRequest>).
2. Сообщение помещается в HTML-форму с полем SAMLResponse (или SAMLRequest для запросов).
3. Форма автоматически отправляется (через JavaScript или пользовательским нажатием) на конечную точку получателя (например, AssertionConsumerService у SP).
4. Получатель извлекает SAML-сообщение из тела POST-запроса, проверяет его подпись (если применимо) и обрабатывает.

Структура сообщения

Формат передачи

Данные передаются в теле HTTP-запроса с MIME-типом application/x-www-form-urlencoded. Основные параметры:

• SAMLRequest — закодированное SAML-сообщение запроса (например, запрос аутентификации).
• SAMLResponse — закодированное SAML-сообщение ответа (содержит утверждения).
• RelayState — необязательный параметр, содержащий идентификатор исходного ресурса, к которому пытался получить доступ пользователь.

Все SAML-сообщения перед передачей:

• Кодируются в Base64 (для безопасной передачи в текстовом виде).
• Опционально сжимаются (для больших сообщений).
• Могут быть подписаны цифровой подписью XML Signature.

Пример HTML-формы

``html <form method="post" action="https://sp.example.com/acs">; <input type="hidden" name="SAMLResponse" value="PHhtbD48... (Base64-encoded)" /> <input type="hidden" name="RelayState" value="https://sp.example.com/protected"; /> <input type="submit" value="Продолжить" /> </form> ``

Применение в SAML

HTTP POST Binding используется в двух основных сценариях:

Инициирование аутентификации (SP-initiated SSO)

1. Пользователь пытается получить доступ к защищённому ресурсу на SP.
2. SP формирует <AuthnRequest> и отправляет его через POST Binding на IdP.
3. IdP аутентифицирует пользователя (например, через логин/пароль).
4. IdP формирует <Response> с утверждением и отправляет его обратно через POST Binding на SP.
5. SP проверяет ответ и предоставляет доступ.

Инициирование поставщиком удостоверений (IdP-initiated SSO)

1. Пользователь уже аутентифицирован на IdP (например, через портал).
2. IdP формирует <Response> с утверждением и отправляет его через POST Binding на SP.
3. SP обрабатывает ответ и предоставляет доступ без дополнительной аутентификации.

Преимущества и недостатки

Преимущества

• Отсутствие ограничений на размер сообщения — позволяет передавать большие XML-документы с расширенными атрибутами и цифровыми подписями.
• Безопасность — данные не отображаются в URL (в отличие от Redirect Binding), что снижает риск утечки через логи сервера или рефереры.
• Простота реализации — не требует сложной обработки на стороне клиента (браузер автоматически отправляет форму).
• Поддержка RelayState — позволяет сохранять контекст запроса (например, исходный URL).

Недостатки

• Зависимость от браузера — требуется, чтобы пользователь находился в веб-сессии (не подходит для сервер-серверных взаимодействий без браузера).
• Проблемы с кэшированием — POST-запросы не кэшируются браузерами, что может увеличить нагрузку.
• Потенциальная уязвимость к CSRF — если не реализована проверка RelayState или не используются anti-CSRF токены.
• Необходимость JavaScript — для автоматической отправки формы (хотя можно использовать кнопку «Продолжить»).

Сравнение с другими биндингами

Реализация в различных системах

Microsoft Active Directory Federation Services (AD FS)

AD FS поддерживает HTTP POST Binding как основной метод для передачи SAML-ответов. В конфигурации AD FS указывается конечная точка AssertionConsumerService с привязкой urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST.

Keycloak

Keycloak (система управления идентификацией с открытым исходным кодом) использует HTTP POST Binding для взаимодействия с SAML-провайдерами. В настройках клиента указывается «POST Binding» как предпочтительный метод.

Google Workspace (ранее G Suite)

Google поддерживает HTTP POST Binding для федерации удостоверений с внешними IdP. В конфигурации указывается URL для приёма SAML-ответов через POST.

Безопасность

Цифровые подписи

Для обеспечения целостности и аутентичности сообщений SAML-документы подписываются с использованием XML Signature (стандарт W3C). Подпись может быть:

• Enveloped — подпись внутри XML-документа.
• Detached — подпись передаётся отдельно (редко используется в POST Binding).

Шифрование

SAML-утверждения могут быть зашифрованы с использованием XML Encryption для защиты конфиденциальных данных (например, атрибутов пользователя).

Защита от CSRF

Рекомендуется:

• Проверять соответствие RelayState исходному запросу.
• Использовать одноразовые токены (nonce).
• Валидировать источник запроса (проверка IP, домена).

Стандартизация

HTTP POST Binding определён в спецификации SAML 2.0 (OASIS Standard, 2005 год) в документе «Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0». Идентификатор биндинга: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST.

Источники

• OASIS Standard. «Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0». March 2005.
• OASIS Standard. «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0». March 2005.
• RFC 2616 — Hypertext Transfer Protocol — HTTP/1.1.
• RFC 4648 — The Base16, Base32, and Base64 Data Encodings.
• W3C Recommendation. «XML Signature Syntax and Processing (Second Edition)». 2008.
• W3C Recommendation. «XML Encryption Syntax and Processing». 2002.