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) omogućava korišćenje provajdera identiteta (IdP) za slanje autorizacionih kredencijala provajderima usluga (SP), olakšavajući jedinstveno prijavljivanje (SSO). Ovaj pristup pojednostavljuje upravljanje višestrukim prijavama omogućavajući korišćenje jednog skupa kredencijala na više veb sajtova. Koristi XML za standardizovanu komunikaciju između IdP-a i SP-a, povezujući autentifikaciju identiteta korisnika sa autorizacijom usluga.
SAML je prilagođen za pružanje preduzećima veće kontrole nad bezbednošću SSO prijavljivanja.
OAuth je dizajniran da bude više prilagođen mobilnim uređajima, koristi JSON i rezultat je saradnje kompanija kao što su Google i Twitter.
Za više detalja pogledajte ceo post sa https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Ovo je sažetak:
Proces SAML autentifikacije uključuje nekoliko koraka, kako je prikazano u šemi:
Pokušaj pristupa resursu: Korisnik pokušava da pristupi zaštićenom resursu.
Generisanje SAML Zahteva: SP ne prepoznaje korisnika i generiše SAML Zahtev.
Preusmeravanje na IdP: Korisnik se preusmerava na IdP, pri čemu SAML Zahtev prolazi kroz korisnikov pretraživač.
IdP prima zahtev: IdP prima SAML Zahtev.
Autentifikacija na IdP: IdP autentifikuje korisnika.
Validacija korisnika: IdP validira legitimnost korisnika za pristup traženom resursu.
Kreiranje SAML Odgovora: IdP generiše SAML Odgovor koji sadrži potrebne tvrdnje.
Preusmeravanje na SP-ovu ACS URL: Korisnik se preusmerava na SP-ovu URL adresu za uslugu potrošnje tvrdnji (ACS).
Validacija SAML Odgovora: ACS validira SAML Odgovor.
Odobren pristup resursu: Pristup inicijalno traženom resursu je odobren.
Razmotrite scenario u kojem korisnik traži pristup sigurnom resursu na https://shibdemo-sp1.test.edu/secure/. SP identifikuje nedostatak autentifikacije i generiše SAML Zahtev:
Raw SAML zahtev izgleda ovako:
Key elements of this request include:
AssertionConsumerServiceURL: Određuje gde IdP treba da pošalje SAML odgovor nakon autentifikacije.
Destination: Adresa IdP-a na koju se zahtev šalje.
ProtocolBinding: Definiše metodu prenosa SAML protokol poruka.
saml:Issuer: Identifikuje entitet koji je inicirao zahtev.
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: Ovaj deo, XML potpis, osigurava integritet i autentičnost izdavaoca asertije. SAML odgovor u primeru sadrži dva ds:Signature elementa, jedan za poruku i drugi za asertiju.
saml:Assertion: Ovaj deo sadrži informacije o identitetu korisnika i moguće druge atribute.
saml:Subject: Određuje glavnog subjekta svih izjava u asertiji.
saml:StatusCode: Predstavlja status operacije kao odgovor na odgovarajući zahtev.
saml:Conditions: Detalji o uslovima kao što su vremenski okvir važenja asertije i određeni provajder usluga.
saml:AuthnStatement: Potvrđuje da je IdP autentifikovao subjekat asertije.
saml:AttributeStatement: Sadrži atribute koji opisuju subjekat asertije.
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:
Each Reference element signifies a specific resource being signed, identifiable by the URI attribute.
Enveloped Signature: Ova vrsta potpisa je potomak resursa koji potpisuje, što znači da je potpis sadržan unutar iste XML strukture kao i potpisani sadržaj.
Example:
In an enveloped signature, the ds:Transform element specifies that it's enveloped through the enveloped-signature algorithm.
Enveloping Signature: U poređenju sa potpisima unutar, potpisivanje resursa obavija resurs koji se potpisuje.
Example:
Detached Signature: Ova vrsta je odvojena od sadržaja koji potpisuje. Potpis i sadržaj postoje nezavisno, ali se održava veza između njih.
Example:
In conclusion, XML Signatures provide flexible ways to secure XML documents, with each type serving different structural and security needs.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
