Парсер 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=PHNhbWxwOlJlc3BvbnNlLz4=

Советы

• 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 мог перенаправить пользователя обратно на страницу, к которой он изначально пытался получить доступ.