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) consente l'utilizzo di fornitori di identità (IdP) per inviare credenziali di autorizzazione ai fornitori di servizi (SP), facilitando il single sign-on (SSO). Questo approccio semplifica la gestione di più accessi consentendo di utilizzare un unico set di credenziali su più siti web. Sfrutta XML per una comunicazione standardizzata tra IdP e SP, collegando l'autenticazione dell'identità dell'utente con l'autorizzazione al servizio.
SAML è progettato per fornire alle aziende un maggiore controllo sulla sicurezza del login SSO.
OAuth è progettato per essere più adatto ai dispositivi mobili, utilizza JSON ed è uno sforzo collaborativo di aziende come Google e Twitter.
Per ulteriori dettagli, controlla il post completo da https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Questo è un riassunto:
Il processo di autenticazione SAML coinvolge diversi passaggi, come illustrato nello schema:
Tentativo di Accesso alla Risorsa: L'utente tenta di accedere a una risorsa protetta.
Generazione della Richiesta SAML: Lo SP non riconosce l'utente e genera una Richiesta SAML.
Reindirizzamento all'IdP: L'utente viene reindirizzato all'IdP, con la Richiesta SAML che passa attraverso il browser dell'utente.
L'IdP Riceve la Richiesta: L'IdP riceve la Richiesta SAML.
Autenticazione presso l'IdP: L'IdP autentica l'utente.
Validazione dell'Utente: L'IdP valida la legittimità dell'utente per accedere alla risorsa richiesta.
Creazione della Risposta SAML: L'IdP genera una Risposta SAML contenente le asserzioni necessarie.
Reindirizzamento all'URL ACS dello SP: L'utente viene reindirizzato all'URL del Servizio di Consumo delle Asserzioni (ACS) dello SP.
Validazione della Risposta SAML: L'ACS valida la Risposta SAML.
Accesso alla Risorsa Consentito: L'accesso alla risorsa inizialmente richiesta è consentito.
Considera lo scenario in cui un utente richiede accesso a una risorsa sicura su https://shibdemo-sp1.test.edu/secure/. Lo SP identifica la mancanza di autenticazione e genera una Richiesta SAML:
La richiesta SAML grezza appare così:
Key elements of this request include:
AssertionConsumerServiceURL: Specifica dove l'IdP dovrebbe inviare la SAML Response dopo l'autenticazione.
Destination: L'indirizzo dell'IdP a cui viene inviata la richiesta.
ProtocolBinding: Definisce il metodo di trasmissione dei messaggi del protocollo SAML.
saml:Issuer: Identifica l'entità che ha avviato la richiesta.
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: Questa sezione, una Firma XML, garantisce l'integrità e l'autenticità dell'emittente dell'asserzione. La SAML response nell'esempio contiene due elementi ds:Signature, uno per il messaggio e l'altro per l'asserzione.
saml:Assertion: Questa parte contiene informazioni sull'identità dell'utente e possibilmente altri attributi.
saml:Subject: Specifica il soggetto principale di tutte le dichiarazioni nell'asserzione.
saml:StatusCode: Rappresenta lo stato dell'operazione in risposta alla richiesta corrispondente.
saml:Conditions: Dettaglia condizioni come il periodo di validità dell'asserzione e il Service Provider specificato.
saml:AuthnStatement: Conferma che l'IdP ha autenticato il soggetto dell'asserzione.
saml:AttributeStatement: Contiene attributi che descrivono il soggetto dell'asserzione.
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:
Ogni elemento Reference indica una risorsa specifica che viene firmata, identificabile dall'attributo URI.
Firma Avvolta: Questo tipo di firma è un discendente della risorsa che firma, il che significa che la firma è contenuta all'interno della stessa struttura XML del contenuto firmato.
Esempio:
In una firma avvolta, l'elemento ds:Transform specifica che è avvolta attraverso l'algoritmo enveloped-signature.
Firma Avvolgente: A differenza delle firme avvolte, le firme avvolgenti avvolgono la risorsa che viene firmata.
Esempio:
Firma Distaccata: Questo tipo è separato dal contenuto che firma. La firma e il contenuto esistono in modo indipendente, ma viene mantenuto un collegamento tra i due.
Esempio:
In conclusione, le firme XML offrono modi flessibili per proteggere i documenti XML, con ciascun tipo che soddisfa diverse esigenze strutturali e di sicurezza.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
