SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Security Assertion Markup Language (SAML) umożliwia wykorzystanie dostawców tożsamości (IdP) do przesyłania poświadczeń autoryzacyjnych do dostawców usług (SP), co ułatwia jednolity dostęp (SSO). To podejście upraszcza zarządzanie wieloma logowaniami, pozwalając na użycie jednego zestawu poświadczeń na wielu stronach internetowych. Wykorzystuje XML do standaryzowanej komunikacji między IdP a SP, łącząc uwierzytelnienie tożsamości użytkownika z autoryzacją usługi.
SAML jest dostosowany do zapewnienia przedsiębiorstwom większej kontroli nad bezpieczeństwem logowania SSO.
OAuth jest zaprojektowany z myślą o większej przyjazności dla urządzeń mobilnych, używa JSON i jest wspólnym wysiłkiem firm takich jak Google i Twitter.
For further details check the full post from https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. This is a summary:
Proces uwierzytelniania SAML obejmuje kilka kroków, jak pokazano w schemacie:
Próba dostępu do zasobu: Użytkownik próbuje uzyskać dostęp do chronionego zasobu.
Generowanie żądania SAML: SP nie rozpoznaje użytkownika i generuje żądanie SAML.
Przekierowanie do IdP: Użytkownik jest przekierowywany do IdP, a żądanie SAML przechodzi przez przeglądarkę użytkownika.
IdP odbiera żądanie: IdP odbiera żądanie SAML.
Uwierzytelnienie w IdP: IdP uwierzytelnia użytkownika.
Walidacja użytkownika: IdP weryfikuje legalność użytkownika do uzyskania dostępu do żądanego zasobu.
Tworzenie odpowiedzi SAML: IdP generuje odpowiedź SAML zawierającą niezbędne asercje.
Przekierowanie do URL ACS SP: Użytkownik jest przekierowywany do URL usługi konsumpcji asercji (ACS) SP.
Walidacja odpowiedzi SAML: ACS weryfikuje odpowiedź SAML.
Dostęp do zasobu przyznany: Przyznano dostęp do początkowo żądanego zasobu.
Rozważmy scenariusz, w którym użytkownik żąda dostępu do zabezpieczonego zasobu na https://shibdemo-sp1.test.edu/secure/. SP identyfikuje brak uwierzytelnienia i generuje żądanie SAML:
Surowe żądanie SAML wygląda tak:
Key elements of this request include:
AssertionConsumerServiceURL: Określa, gdzie IdP powinien wysłać odpowiedź SAML po uwierzytelnieniu.
Destination: Adres IdP, do którego wysyłane jest żądanie.
ProtocolBinding: Definiuje metodę transmisji wiadomości protokołu SAML.
saml:Issuer: Identyfikuje podmiot, który zainicjował żądanie.
Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.
You can find a full SAML response here. The key components of the response include:
ds:Signature: Ta sekcja, podpis XML, zapewnia integralność i autentyczność wystawcy asercji. Odpowiedź SAML w przykładzie zawiera dwa elementy ds:Signature, jeden dla wiadomości, a drugi dla asercji.
saml:Assertion: Ta część zawiera informacje o tożsamości użytkownika i ewentualnie inne atrybuty.
saml:Subject: Określa główny podmiot wszystkich stwierdzeń w asercji.
saml:StatusCode: Reprezentuje status operacji w odpowiedzi na odpowiadające żądanie.
saml:Conditions: Szczegóły dotyczące warunków, takich jak czas ważności asercji i określony dostawca usług.
saml:AuthnStatement: Potwierdza, że IdP uwierzytelnił podmiot asercji.
saml:AttributeStatement: Zawiera atrybuty opisujące podmiot asercji.
Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState and SAMLResponse parameters. The ACS is responsible for processing and validating the SAML Response.
After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET request to the /secure/ endpoint and a 200 OK response, indicating successful access to the resource.
XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:
An XML Signature consists of essential elements as shown:
Każdy element Reference oznacza konkretny zasób, który jest podpisywany, identyfikowalny za pomocą atrybutu URI.
Podpis osadzony: Ten typ podpisu jest potomkiem zasobu, który podpisuje, co oznacza, że podpis jest zawarty w tej samej strukturze XML co podpisana treść.
Przykład:
W podpisie osadzonym element ds:Transform określa, że jest on osadzony za pomocą algorytmu enveloped-signature.
Podpis otaczający: W przeciwieństwie do podpisów osadzonych, podpisy otaczające owijają zasób, który jest podpisywany.
Przykład:
Podpis oddzielony: Ten typ jest oddzielony od treści, którą podpisuje. Podpis i treść istnieją niezależnie, ale utrzymywany jest między nimi link.
Przykład:
Podsumowując, podpisy XML oferują elastyczne sposoby zabezpieczania dokumentów XML, z każdym typem spełniającym różne potrzeby strukturalne i bezpieczeństwa.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
