Binding HTTP-Redirect¶

Nel caso del binding HTTP-Redirect la richiesta viene veicolata con le seguenti modalità:

1. L’entità mittente invia allo User Agent un messaggio HTTP di redirezione, cioè avente uno status code con valore 302 («Found») o 303 («See Other»).
2. Il Location Header del messaggio HTTP contiene l’URI di destinazione del servizio esposto dall’entità destinataria.
3. Il browser dell’utente elabora quindi tale messaggio HTTP-Redirect indirizzando una richiesta HTTP con metodo GET al servizio dell’entità destinataria sotto forma di URL con tutti i sopraindicati parametri contenuti nella query string.

Il messaggio HTTP trasporta i seguenti parametri (tutti URL-encoded):

SAMLRequest

Un costrutto SAML codificato in formato Base64 e compresso con algoritmo DEFLATE. Come da specifica, il messaggio SAML non contiene la firma in formato XML Digital Signature esteso (come avviene in generale nel caso di binding HTTP-POST). Ciò a causa delle dimensioni eccessive che esso raggiungerebbe per essere veicolato in una query string. La specifica indica come modalità alternativa quella di specificare con parametri aggiuntivi l’algoritmo utilizzato per firmare (SigAlg) e la stringa con la codifica Base64 URL-encoded dei byte del messaggio SAML (Signature).

RelayState

Identifica la risorsa (servizio) originariamente richiesta dall’utente e a cui trasferire il controllo alla fine del processo di autenticazione. Il Service Provider a tutela della privacy dell’utente nell’utilizzare questo parametro deve mettere in atto accorgimenti tali da rendere minima l’evidenza possibile sulla natura o tipologia della risorsa (servizio) richiesta

SigAlg

Identifica l’algoritmo usato per la firma prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore; il valore esteso di questo parametro è contestualizzato da un namespace appartenente allo standard XML Digital Signature. Come indicato al punto 1, tuttavia, la firma prodotta non fa uso della struttura XML definita in tale standard

Signature

Contiene la firma digitale della query string, così come prodotta prima di aggiungere questo parametro, utilizzando l’algoritmo indicato al parametro precedente;

Un esempio di tale URL è il seguente, nel quale sono evidenziati in grassetto i parametri citati (i valori di alcuni parametri sono stati ridotti per brevità, inoltre il valore del parametro RelayState è stato reso non immediatamente intellegibile, come suggerito dalla specifica, sostituendo la stringa in chiaro con l’ID della richiesta: l’entità mittente tiene traccia della corrispondenza)

SAMLRequest=nVPLbtswELz3KwTeZb0M2SYsBa6NoAbSRrGUHnqjqFVDQCJVLuU4f19KlhEDb
VygR5K7O7Mzw%2FXdqW2cI2gUSiYkmPnEAclVJeTPhDwX%2B6S3KWf1sjapqOb3rzIA%2FzqAY2zQQRtbNtWSe
[...]
ZwPAU88aUQvQ%2F8oe8S68piBDNabB5s3AyThb1XZMCxxEhhPj5qLZddW2sZIcoP4fBW%2BWccqH0fZ6iNir0tU
QGeCWZaGZxE5pM4n8Nz7p%2Be2D3S6L51x1NljO%2BCO2qh8zO%2Bji%2FfnN098%3D&RelayState=s29f6c7d
6bbf9e62968d27309e2e4beb6133663a2e&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig
%23rsa-sha1&Signature=LtNj%2BbMc8j%2FhglWzHPMmo0ESQzBaWlmQbZxas%2B%2FIfNO4F%2F7WNoMKDZ4
VVYeBtCEQKWp12pU7vPB5WVVMRMrGB8ZRAdHmmPp0hJ9opO3NdafRc04Z%2BbfnkSuQCN9NcGV%2BajT
[...]
ra169jhaGRReRQ9KkgSB3aTpQGaffAYUPVo2XZiWy6f9Z7zsmV%2FFoT8dg%3D%3D

Binding HTTP-POST¶

Nel caso del binding HTTP-POST, l’entità mittente invia allo User Agent (il browser dell’utente) un messaggio HTTP con status code avente valore 200 («OK»):

1. Il messaggio HTTP contiene una form HTML all’interno della quale è trasportato un costrutto SAML codificato come valore di un hidden form control di nome SAMLRequest oppure SAMLResponse. Rispetto al binding HTTP-Redirect, l’utilizzo di una form HTML permette di superare i limiti di dimensione della query string. Pertanto, l’intero messaggio SAML in formato XML può essere firmato in accordo alla specifica XML Digital Signature. Il risultato a valle della firma è quindi codificato in formato Base64
   • Il parametro deve essere denominato SAMLRequest nel trasporto dei messaggi <AuthnRequest> e LogoutRequest, mentre deve essere denominato SAMLResponse nel trasporto dei messaggi <Response> e <LogoutResponse>.
2. La form HTML contiene un secondo hidden form control di nome RelayState che contiene il corrispondente valore del Relay State, cioè della risorsa originariamente richiesta dall’utente e alla quale dovrà essere trasferito il controllo al termine della fase di autenticazione
3. La form HTML è corredata da uno script che la rende auto-postante all’indirizzo indicato nell’attributo action corrispondente alla Location del SingleSignOnService.
4. Il browser dell’utente elabora quindi la risposta HTTP e invia una richiesta HTTP POST verso il servizio dell’entità destinataria.

Un esempio di form HTML per trasferire in HTTP-POST la richiesta di autenticazione è descritto nell’esempio successivo. Osservando attentamente il codice riportato in figura si può notare il valore del parametro SAMLRequest (ridotto per brevità); il valore del parametro RelayState reso non immediatamente intellegibile (cfr. sez. precedente); l’elemento <input type="submit" value="Invia"/>, che ha lo scopo di visualizzare all’interno del web browser il pulsante di invio della form utilizzabile dall’utente, non strettamente necessario in quanto la form è resa autopostante.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

<html>
    <head>
        [...]
    </head>
    <body onload="javascript:document.forms[0].submit()">
        <form method="post" action="https://spid.identityprovider.it/SSOServiceProxy">
            <input type="hidden" name="SAMLRequest"
                value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZVRGLTgiPz4KPHNhbWxwOkF1dGhuUmVxdWVzdCBB
                c3NlcnRpb25Db25zdW1lclNlcnZpY2VVUkw9Imh0dHA6Ly9zcC5pY2FyLml0OjgwODAvaWNhc
                [...]
                N0ZWRUcmFuc3BvcnQ8L3NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvb
                nRleHQ+PHNhbWxwOlNjb3BpbmcgUHJveHlDb3VudD0iMiIgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0
                YzpTQU1MOjIuMDpwcm90b2NvbCIvPjwvc2FtbG5SZXF1ZXN0Pg==">
            <input type="hidden" name="RelayState" value="s2645f48777bd62ec83eddc62...">
            <input type="submit" value="Invia"/>
        </form>
    </body>
</html>

Un esempio di form HTML per trasferire in HTTP-POST la risposta ad una richiesta di autenticazione è descritto nell’esempio successivo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

<html>
    <head>
        [...]
    </head>
    <body onload="javascript:document.forms[0].submit()">
        <form method="post" action="https://spid.serviceprovider.it/AssertionConsumerService">
            <input type="hidden" name="SAMLResponse"
                value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNhbWxwOlJlc3BvbnNlIERlc3Rp
                bmF0aW9uPSJodHRwOi8vc3AuaWNhci5pdDo4MDgwL2ljYXItc3AvQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIiB
                JRD0iczJhNTdmN2RhYTUyMTc2NWZmOTQ2ODM0ZmY2NjIzNTA3ZTcwNGI1MDQ3IiBJblJlc3BvbnNlVG89InMyOG
                Q5MWEyNmJkNGQ2MGY0N2E0OTkxMzMwMGZhZjc2MzFiZjMxNDBlOSIgSXNzdWVJbnN0YW50PSIyMDA4LTAzLTA0V
                DIyOjEzOjQ4LjUwMFoiIFZlcnNpb249IjIuMCIgeG1sbnM6c2Ftb
                [...]
                2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmRQcm90ZWN0ZWRUcmFuc3BvcnQ8L3NhbWw6
                QXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9zYW1sOkF1dGhuQ29udGV4dD48L3NhbWw6QXV0aG5TdGF0ZW1lbnQ+PC9
                zYW1sOkFzc2VydGlvbj48L3NhbWxwOlJlc3BvbnNlPg==">
            <input type="hidden" name="RelayState" value="s28d91a26bd4d60f47a49913300f...">
            <input type="submit" value="Invia"/>
        </form>
    </body>
</html>

Sicurezza¶

Il profilo SAML SSO raccomanda l’uso di TLS 1.2 nei colloqui tra Asserting party (Identity Provider e Attribute Authority), le Relaying Party (Service Provider) e lo user agent. In ambito SPID si rende obbligatorio l’impiego di TLS 1.2. In casi particolari e temporanei, può essere adottata la versione 1.1, fermo restando che la versione 1.2 deve essere adottata lato server. Conseguentemente, le versioni più obsolete dei browser, che non supportano le versioni del protocollo indicate, non devono essere utilizzate e, i livelli minimi accettati per l’accesso ai servizi SPID, devono essere documentati nei confronti degli utenti.