Парсер SAML

SAML (Security Assertion Markup Language) — это основанный на XML стандарт для обмена данными аутентификации и авторизации между провайдерами идентификации (IdP) и поставщиками услуг (SP). Этот инструмент декодирует SAML-сообщения из URL, обрабатывает кодирование Base64 и сжатие DEFLATE, и форматирует XML для проверки.

Спецификации

• OASIS SAML 2.0 Core
• OASIS SAML 2.0 Bindings
• SAML 2.0 Technical Overview

Типичные сценарии использования

• Отладка потоков аутентификации Enterprise Single Sign-On (SSO)
• Просмотр SAML-утверждений от провайдеров идентификации (Okta, Azure AD, ADFS)
• Устранение неполадок интеграции SAML между сервисами
• Проверка атрибутов утверждения и значений NameID
• Анализ AuthnContext и параметров сессии
• Аудит конфигураций SAML для проверки безопасности

Возможности

• Разбор сообщений SAML AuthnRequest (SP к IdP)
• Декодирование SAML Response и Assertion (IdP к SP)
• Извлечение SAMLRequest и SAMLResponse из параметров URL
• Обработка кодирования Base64 и сжатия DEFLATE (привязка HTTP-Redirect)
• Форматированный вывод структуры XML с подсветкой синтаксиса
• Отображение обзора сообщения (тип, ID, IssueInstant, Destination, Status)
• Извлечение Issuer, Subject/NameID и Conditions
• Отображение атрибутов утверждения из AttributeStatement
• Индикатор наличия подписи

Примеры

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIElEPSJfcmVzcDEyMyIgVmVyc2lvbj0iMi4wIiBJc3N1ZUluc3RhbnQ9IjIwMjYtMDMtMjdUMTA6MDA6MDBaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9zcC5leGFtcGxlLmNvbS9hY3MiPjxzYW1sOklzc3Vlcj5odHRwczovL2lkcC5leGFtcGxlLmNvbTwvc2FtbDpJc3N1ZXI+PHNhbWxwOlN0YXR1cz48c2FtbHA6U3RhdHVzQ29kZSBWYWx1ZT0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnN0YXR1czpTdWNjZXNzIi8+PC9zYW1scDpTdGF0dXM+PHNhbWw6QXNzZXJ0aW9uIElEPSJfYXNzZXJ0NDU2IiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAyNi0wMy0yN1QxMDowMDowMFoiPjxzYW1sOklzc3Vlcj5odHRwczovL2lkcC5leGFtcGxlLmNvbTwvc2FtbDpJc3N1ZXI+PHNhbWw6U3ViamVjdD48c2FtbDpOYW1lSUQgRm9ybWF0PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoxLjE6bmFtZWlkLWZvcm1hdDplbWFpbEFkZHJlc3MiPnVzZXJAZXhhbXBsZS5jb208L3NhbWw6TmFtZUlEPjwvc2FtbDpTdWJqZWN0PjxzYW1sOkNvbmRpdGlvbnMgTm90QmVmb3JlPSIyMDI2LTAzLTI3VDA5OjU1OjAwWiIgTm90T25PckFmdGVyPSIyMDI2LTAzLTI3VDEwOjA1OjAwWiI+PHNhbWw6QXVkaWVuY2VSZXN0cmljdGlvbj48c2FtbDpBdWRpZW5jZT5odHRwczovL3NwLmV4YW1wbGUuY29tPC9zYW1sOkF1ZGllbmNlPjwvc2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPjwvc2FtbDpDb25kaXRpb25zPjxzYW1sOkF0dHJpYnV0ZVN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGUgTmFtZT0iZW1haWwiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlPnVzZXJAZXhhbXBsZS5jb208L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48c2FtbDpBdHRyaWJ1dGUgTmFtZT0icm9sZSI+PHNhbWw6QXR0cmlidXRlVmFsdWU+YWRtaW48L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48L3NhbWw6QXR0cmlidXRlU3RhdGVtZW50Pjwvc2FtbDpBc3NlcnRpb24+PC9zYW1scDpSZXNwb25zZT4%3D

Советы

• SAML использует два основных типа привязки: HTTP-Redirect (GET с deflate+base64) и HTTP-POST (POST с base64).
• Параметр RelayState сохраняет изначально запрошенный URL в течение потока SSO.
• SAML-утверждения могут быть подписаны, зашифрованы или и то, и другое. Этот инструмент показывает декодированное содержимое.
• Проверяйте условия NotBefore и NotOnOrAfter для валидации временных параметров утверждения.

Описание Парсер SAML

SAML (Security Assertion Markup Language) — это открытый стандарт на основе XML для обмена данными аутентификации и авторизации между провайдером идентификации (IdP) и поставщиком услуг (SP). SAML 2.0, опубликованный OASIS в 2005 году, остаётся доминирующим протоколом для корпоративного единого входа (SSO), позволяя сотрудникам аутентифицироваться один раз и получать доступ к нескольким приложениям.

Поток SAML SSO работает следующим образом: пользователь пытается получить доступ к поставщику услуг, SP генерирует AuthnRequest и перенаправляет браузер к IdP, IdP аутентифицирует пользователя и создаёт SAML Response, содержащий Assertion, а браузер отправляет этот Response обратно SP через POST. Утверждение содержит идентификатор пользователя (NameID), атрибуты (email, группы, роли) и условия (окно валидности, ограничение аудитории).

SAML-сообщения передаются с помощью привязок. Привязка HTTP-Redirect кодирует XML с использованием сжатия DEFLATE и кодирования Base64 в параметре URL-запроса. Привязка HTTP-POST использует только Base64 и отправляет через автоматически отправляемую форму. Отладка SAML требует декодирования этих слоёв для просмотра базового XML.

SAML-утверждения могут быть подписаны (чтобы доказать, что они получены от IdP), зашифрованы (чтобы предотвратить чтение содержимого посредниками) или и то, и другое. При устранении неполадок SSO первым шагом всегда является декодирование SAML Response и проверка условий, аудитории, временных меток и значений атрибутов утверждения.

SAML и OAuth 2.0/OpenID Connect служат разным целям. SAML предназначен для корпоративного SSO с использованием XML-утверждений, передаваемых через перенаправления браузера, и наиболее распространён в корпоративных средах с провайдерами идентификации, такими как ADFS и Okta. OAuth 2.0 — это фреймворк авторизации для доступа к API с использованием JSON-токенов, а OpenID Connect добавляет слой аутентификации поверх OAuth с использованием JWT. OIDC более распространён в современных веб- и мобильных приложениях, тогда как SAML остаётся доминирующим в корпоративных IT-средах.

SAML-сообщения часто выглядят как непонятные строки, поскольку они закодированы для передачи. При привязке HTTP-POST XML кодируется в Base64. При привязке HTTP-Redirect XML сначала сжимается DEFLATE, затем кодируется в Base64 и далее URL-кодируется. Чтение оригинального XML требует обращения этих слоёв в правильном порядке. Этот инструмент автоматически обрабатывает все этапы декодирования вне зависимости от использованной привязки.

При устранении ошибок SAML проверьте несколько распространённых причин: расхождение часов между IdP и SP может привести к ошибке валидации временных меток утверждения; элемент Audience должен точно совпадать с настроенным Entity ID SP; срок действия утверждений может истечь (NotOnOrAfter); атрибут Destination должен совпадать с URL Assertion Consumer Service (ACS) SP; SP может не иметь актуального сертификата подписи IdP, если он был недавно обновлён. Параметр RelayState также играет важную роль в потоке SSO — он сохраняет изначально запрошенный пользователем URL через перенаправление аутентификации, чтобы после успешной аутентификации SP мог перенаправить пользователя обратно на страницу, к которой он изначально пытался получить доступ.