Parser SAML

SAML (Security Assertion Markup Language) to oparty na XML standard wymiany danych uwierzytelniania i autoryzacji między dostawcami tożsamości (IdP) a dostawcami usług (SP). To narzędzie dekoduje wiadomości SAML z URL-i, obsługuje kodowanie Base64 i kompresję DEFLATE oraz formatuje XML do inspekcji.

Specyfikacje

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

Typowe zastosowania

• Debugowanie przepływów uwierzytelniania Enterprise Single Sign-On (SSO)
• Inspekcja asercji SAML od dostawców tożsamości (Okta, Azure AD, ADFS)
• Rozwiązywanie problemów z integracją SAML między usługami
• Weryfikacja atrybutów asercji i wartości NameID
• Analiza AuthnContext i parametrów sesji
• Audyt konfiguracji SAML pod kątem przeglądu bezpieczeństwa

Funkcje

• Parsowanie wiadomości SAML AuthnRequest (SP do IdP)
• Dekodowanie SAML Response i Assertion (IdP do SP)
• Wyodrębnianie SAMLRequest i SAMLResponse z parametrów zapytania URL
• Obsługa kodowania Base64 i kompresji DEFLATE (wiązanie HTTP-Redirect)
• Formatowanie struktury XML z podświetlaniem składni
• Wyświetlanie przeglądu wiadomości (typ, ID, IssueInstant, Destination, Status)
• Wyodrębnianie Issuer, Subject/NameID i Conditions
• Wyświetlanie atrybutów asercji z AttributeStatement
• Wskaźnik obecności podpisu

Przyklady

https://sp.example.com/acs?SAMLResponse=PHNhbWxwOlJlc3BvbnNlLz4=

Wskazowki

• SAML używa dwóch głównych wiązań: HTTP-Redirect (GET z deflate+base64) i HTTP-POST (POST z base64).
• Parametr RelayState zachowuje pierwotnie żądany URL w trakcie przepływu SSO.
• Asercje SAML mogą być podpisane, zaszyfrowane lub jedno i drugie. To narzędzie pokazuje zdekodowaną zawartość.
• Sprawdź warunki NotBefore i NotOnOrAfter, aby zweryfikować ważność czasową asercji.

Zrozumienie Parser SAML

SAML (Security Assertion Markup Language) to otwarty standard oparty na XML do wymiany danych uwierzytelniania i autoryzacji między dostawcą tożsamości (IdP) a dostawcą usług (SP). SAML 2.0, opublikowany przez OASIS w 2005 roku, pozostaje dominującym protokołem dla korporacyjnego jednokrotnego logowania (SSO), umożliwiając pracownikom jednokrotne uwierzytelnienie i dostęp do wielu aplikacji.

Przepływ SAML SSO działa w następujący sposób: użytkownik próbuje uzyskać dostęp do dostawcy usług, SP generuje AuthnRequest i przekierowuje przeglądarkę do IdP, IdP uwierzytelnia użytkownika i tworzy SAML Response zawierający Assertion, a przeglądarka wysyła ten Response przez POST z powrotem do SP. Asercja zawiera tożsamość użytkownika (NameID), atrybuty (email, grupy, role) i warunki (okno ważności, ograniczenie odbiorców).

Wiadomości SAML są transportowane za pomocą wiązań. Wiązanie HTTP-Redirect koduje XML przy użyciu kompresji DEFLATE i kodowania Base64 w parametrze zapytania URL. Wiązanie HTTP-POST używa tylko Base64 i wysyła przez automatycznie przesyłany formularz. Debugowanie SAML wymaga dekodowania tych warstw w celu inspekcji bazowego XML.

Asercje SAML mogą być podpisane (aby udowodnić, że pochodzą od IdP), zaszyfrowane (aby uniemożliwić pośrednikom odczytanie zawartości) lub jedno i drugie. Przy rozwiązywaniu problemów z SSO pierwszym krokiem jest zawsze dekodowanie SAML Response i sprawdzenie warunków, odbiorców, znaczników czasu i wartości atrybutów asercji.

SAML i OAuth 2.0/OpenID Connect służą różnym celom. SAML jest przeznaczony do korporacyjnego SSO przy użyciu asercji opartych na XML transportowanych przez przekierowania przeglądarki i jest najczęściej spotykany w środowiskach korporacyjnych z dostawcami tożsamości takimi jak ADFS i Okta. OAuth 2.0 to framework autoryzacji dla dostępu do API przy użyciu tokenów JSON, a OpenID Connect dodaje warstwę uwierzytelniania na OAuth przy użyciu JWT. OIDC jest bardziej powszechny w nowoczesnych aplikacjach webowych i mobilnych, podczas gdy SAML pozostaje dominujący w korporacyjnych środowiskach IT.

Wiadomości SAML często wyglądają jak niezrozumiałe ciągi znaków, ponieważ są zakodowane do transportu. W wiązaniu HTTP-POST XML jest kodowany w Base64. W wiązaniu HTTP-Redirect XML jest najpierw kompresowany DEFLATE, następnie kodowany w Base64, a potem kodowany jako URL. Odczytanie oryginalnego XML wymaga odwrócenia tych warstw we właściwej kolejności. To narzędzie automatycznie obsługuje wszystkie kroki dekodowania niezależnie od użytego wiązania.

Przy rozwiązywaniu błędów SAML sprawdź kilka częstych przyczyn: różnica zegarów między IdP a SP może powodować niepowodzenie walidacji znaczników czasu asercji; element Audience musi dokładnie odpowiadać skonfigurowanemu Entity ID SP; asercje mogły przekroczyć czas NotOnOrAfter; atrybut Destination musi odpowiadać URL Assertion Consumer Service (ACS) SP; oraz SP może nie mieć aktualnego certyfikatu podpisującego IdP, jeśli został niedawno wymieniony. Parametr RelayState również odgrywa ważną rolę w przepływie SSO — zachowuje pierwotnie żądany przez użytkownika URL przez przekierowanie uwierzytelniania, dzięki czemu po udanym uwierzytelnieniu SP może przekierować z powrotem na stronę, do której użytkownik początkowo próbował uzyskać dostęp.