SAML Basics
Panoramica di SAML
Security Assertion Markup Language (SAML) consente ai provider di identità (IdP) di inviare credenziali di autorizzazione ai provider di servizi (SP), facilitando l'accesso tramite single sign-on (SSO). Questo approccio semplifica la gestione di accessi multipli consentendo l'utilizzo di un unico set di credenziali su più siti web. SAML sfrutta XML per la comunicazione standardizzata tra IdP e SP, collegando l'autenticazione dell'identità dell'utente con l'autorizzazione del servizio.
Confronto tra SAML e OAuth
SAML è progettato per fornire alle aziende un maggiore controllo sulla sicurezza dell'accesso SSO.
OAuth è progettato per essere più adatto ai dispositivi mobili, utilizza JSON ed è un'opera collaborativa di aziende come Google e Twitter.
Flusso di autenticazione SAML
Per ulteriori dettagli consulta il post completo su 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 prevede diversi passaggi, come illustrato nello schema:
Tentativo di accesso alla risorsa: L'utente cerca 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.
Ricezione della richiesta da parte dell'IdP: L'IdP riceve la richiesta SAML.
Autenticazione presso l'IdP: L'IdP autentica l'utente.
Convalida dell'utente: L'IdP convalida la legittimità dell'utente per accedere alla risorsa richiesta.
Creazione della risposta SAML: L'IdP genera una risposta SAML contenente le affermazioni necessarie.
Reindirizzamento all'URL ACS dello SP: L'utente viene reindirizzato all'URL del servizio di consumo delle affermazioni (ACS) dello SP.
Convalida della risposta SAML: L'ACS convalida la risposta SAML.
Accesso alla risorsa consentito: Viene concesso l'accesso alla risorsa inizialmente richiesta.
Esempio di richiesta SAML
Considera lo scenario in cui un utente richiede l'accesso a una risorsa protetta su https://shibdemo-sp1.test.edu/secure/. Lo SP rileva l'assenza di autenticazione e genera una richiesta SAML:
La richiesta SAML grezza si presenta così:
Gli elementi chiave di questa richiesta includono:
AssertionConsumerServiceURL: Specifica dove l'IdP deve inviare la risposta SAML 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.
Dopo la generazione della richiesta SAML, il SP risponde con un redirect 302, indirizzando il browser all'IdP con la richiesta SAML codificata nell'intestazione Location della risposta HTTP. Il parametro RelayState mantiene le informazioni di stato durante l'intera transazione, garantendo che il SP riconosca la richiesta iniziale della risorsa al momento della ricezione della risposta SAML. Il parametro SAMLRequest è una versione compressa e codificata dello snippet XML grezzo, utilizzando la compressione Deflate e la codifica base64.
Esempio di risposta SAML
Puoi trovare una risposta SAML completa qui. I componenti chiave della risposta includono:
ds:Signature: Questa sezione, una firma XML, garantisce l'integrità e l'autenticità dell'emittente dell'asserzione. La risposta SAML 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 eventualmente 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 le condizioni come la validità temporale 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.
Dopo la risposta SAML, il processo include un redirect 302 dall'IdP. Ciò porta a una richiesta POST all'URL del Service Provider's Assertion Consumer Service (ACS). La richiesta POST include i parametri RelayState e SAMLResponse. L'ACS è responsabile del processo di elaborazione e convalida della risposta SAML.
Dopo aver ricevuto la richiesta POST e convalidato la risposta SAML, viene concesso l'accesso alla risorsa protetta inizialmente richiesta dall'utente. Questo viene illustrato con una richiesta GET all'endpoint /secure/ e una risposta 200 OK, che indica un accesso riuscito alla risorsa.
Firme XML
Le firme XML sono versatili e in grado di firmare un'intera struttura XML o elementi specifici al suo interno. Possono essere applicate a qualsiasi oggetto XML, non solo agli elementi di risposta. Di seguito sono riportati i tipi chiave di firme XML:
Struttura di base della firma XML
Una firma XML è composta dagli elementi essenziali mostrati di seguito:
Ogni elemento Reference indica una risorsa specifica che viene firmata, identificabile dall'attributo URI.
Tipi di Firme XML
Firma Inclusa: Questo tipo di firma è un discendente della risorsa che firma, il che significa che la firma è contenuta nella stessa struttura XML del contenuto firmato.
Esempio:
In una firma inclusa, l'elemento ds:Transform specifica che è inclusa tramite l'algoritmo enveloped-signature.
Firma Avvolgente: A differenza delle firme incluse, le firme avvolgenti avvolgono la risorsa che viene firmata.
Esempio:
Firma Separata: Questo tipo è separato dal contenuto che firma. La firma e il contenuto esistono indipendentemente, ma viene mantenuto un collegamento tra i due.
Esempio:
In conclusione, le Firme XML forniscono modi flessibili per proteggere i documenti XML, con ogni tipo che soddisfa diverse esigenze strutturali e di sicurezza.
Riferimenti
Last updated
