Декодер SAML

Инструмент поддерживает Base64-кодированные SAML Response и Assertion XML, обычно встречающиеся в SAML-перенаправлениях и POST-привязках. Он также автоматически определяет и распаковывает deflate-сжатые SAML-запросы.

Да. Вся обработка выполняется полностью в вашем браузере. Ваши токены SAML никогда не отправляются на какой-либо сервер. Никакие данные не покидают ваше устройство.

SAML-запросы, отправляемые через HTTP-перенаправление, часто сжимаются deflate перед кодированием Base64 для уменьшения длины URL. Этот инструмент автоматически определяет и распаковывает такие данные.

Запрос — это samlp:AuthnRequest, который поставщик услуг отправляет, чтобы попросить поставщика идентификационных данных аутентифицировать пользователя; ответ — это samlp:Response, который приходит обратно и содержит saml:Assertion с утверждением аутентификации и атрибутами. Оба передаются в URL-кодированном виде (Redirect binding) или внутри HTML-формы POST (POST binding). Этот инструмент декодирует любое из направлений.

Непрозрачная строка, которую SP добавляет к запросу и которую IdP должен вернуть без изменений вместе с ответом — обычно это URL для перенаправления после входа. Спецификация SAML bindings рекомендует держать её в пределах 80 байт, и для IdP она не несёт никакого смысла. Если SSO приводит не на ту страницу, первое подозрение — потерянный или повреждённый RelayState.

В HTTP-Redirect binding XML сначала сжимается raw-Deflate, затем кодируется в Base64, затем URL-кодируется — три обязательных шага согласно спецификации. Передайте этому инструменту URL-кодированное значение: если оно разворачивается в разметку, начинающуюся с <, значит данные были сжаты; если оно уже начинается с <?xml или <saml — не были. Сообщения в POST binding — это просто Base64 без Deflate.

Рассинхронизация часов — проверка подписи завершается ошибкой, когда часы SP и IdP расходятся больше, чем допускается; несоответствие аудитории — audienceRestriction в утверждении не содержит entity ID поставщика услуг; и истёкшие ответы (NotOnOrAfter). Также часто встречаются: отсутствующий RelayState и неподписанные утверждения там, где SP требует подпись. Декодированные поля, которые показывает этот инструмент, позволяют проверить каждую из этих причин напрямую.

Да — декодирование не является проверкой. XML утверждения может прочитать кто угодно; подпись внутри обеспечивает целостность, а не конфиденциальность. Без публичного сертификата IdP нельзя доказать, что утверждение подлинно и не было изменено. Обращайтесь с любым декодированным содержимым осторожно: утверждения часто содержат адреса электронной почты, группы и права доступа.