Panoramica di SAML

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 l'uso di 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.

Confronto tra SAML e OAuth

• SAML è progettato per fornire alle imprese un maggiore controllo sulla sicurezza dell'accesso SSO.
• OAuth è progettato per essere più adatto ai dispositivi mobili, utilizza JSON ed è uno sforzo collaborativo di aziende come Google e Twitter.

Flusso di Autenticazione SAML

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:

1. Tentativo di Accesso alla Risorsa: L'utente tenta di accedere a una risorsa protetta.
2. Generazione della Richiesta SAML: Lo SP non riconosce l'utente e genera una Richiesta SAML.
3. Reindirizzamento all'IdP: L'utente viene reindirizzato all'IdP, con la Richiesta SAML che passa attraverso il browser dell'utente.
4. IdP Riceve la Richiesta: L'IdP riceve la Richiesta SAML.
5. Autenticazione presso l'IdP: L'IdP autentica l'utente.
6. Validazione dell'Utente: L'IdP valida la legittimità dell'utente per accedere alla risorsa richiesta.
7. Creazione della Risposta SAML: L'IdP genera una Risposta SAML contenente le asserzioni necessarie.
8. Reindirizzamento all'URL ACS dello SP: L'utente viene reindirizzato all'URL del Servizio Consumatore di Asserzioni (ACS) dello SP.
9. Validazione della Risposta SAML: L'ACS valida la Risposta SAML.
10. Accesso alla Risorsa Consentito: L'accesso alla risorsa inizialmente richiesta è consentito.

Esempio di Richiesta SAML

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:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

La richiesta SAML grezza appare così:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Elementi chiave di questa richiesta includono:

• 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.

Dopo la generazione della richiesta SAML, lo SP risponde con un 302 redirect, 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 la transazione, assicurando che lo SP riconosca la richiesta di risorsa iniziale al ricevimento della SAML Response. Il parametro SAMLRequest è una versione compressa e codificata del frammento XML grezzo, utilizzando la compressione Deflate e la codifica base64.

Esempio di SAML Response

Puoi trovare una full SAML response here. I componenti chiave della risposta includono:

• 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 le 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.

Dopo la SAML Response, il processo include un 302 redirect dall'IdP. Questo 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 dell'elaborazione e della validazione della SAML Response.

Dopo che la richiesta POST è stata ricevuta e la SAML Response è stata validata, l'accesso viene concesso alla risorsa protetta inizialmente richiesta dall'utente. Questo è illustrato con una richiesta GET all'endpoint /secure/ e una risposta 200 OK, che indica l'accesso riuscito alla risorsa.

Firme XML

Le firme XML sono versatili, capaci di firmare un intero albero 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 consiste di elementi essenziali come mostrato:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Ogni elemento Reference indica una risorsa specifica che viene firmata, identificabile dall'attributo URI.

Tipi di firme XML

1. 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:

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

In una firma avvolta, l'elemento ds:Transform specifica che è avvolta attraverso l'algoritmo enveloped-signature.

2. Firma Avvolgente: A differenza delle firme avvolte, le firme avvolgenti avvolgono la risorsa che viene firmata.

Esempio:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>

3. 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:

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

In conclusione, le firme XML offrono modi flessibili per proteggere i documenti XML, con ciascun tipo che soddisfa diverse esigenze strutturali e di sicurezza.

Riferimenti

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/