Disponibilità dei metadata¶

I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso la URL https://<dominioGestoreIdentita>/metadata, ove non diversamente specificato nel Registro SPID, e saranno firmate in modalita detached dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

I metadata dei Service Provider saranno disponibili per tutte le entità SPID federate attraverso la URL https://<dominioServiceProvider>/metadata e saranno firmate dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

Identity Provider¶

Le caratteristiche dell’Identity provider sono definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettano le condizioni di seguito indicate:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

<md:EntityDescriptor xmlns:md = "urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
    xmlns:fpa="https://spid.gov.it/invoicing-extensions"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="http://spid.identityprovider.it"
    ID="_2ini49248n98dn984n...">
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        [...]
    </ds:Signature>
    <md:IDPSSODescriptor
        protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
        WantAuthnRequestsSigned="true">
        <md:KeyDescriptor use="signing">...</md:KeyDescriptor>
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://spid.identityprovider.it/Post-Post-saml2slo"
            ResponseLocation="https://spid.identityprovider.it/Post-Post-saml2slo"/>
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
            Location="https://spid.identityprovider.it/redirect-Post-saml2slo"
            ResponseLocation="https://spid.identityprovider.it/redirect-Post-saml2slo"/>
        <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
        <md:SingleSignOnService
            Location="https://spid.identityprovider.it/redirect-Post-saml2sso"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
        <md:SingleSignOnService
            Location="https://spid.identityprovider.it/Post-Post-saml2sso"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <saml:Attribute xsi:type="xsi:string" Name="familyName"/>
        <saml:Attribute xsi:type="xsi:string" Name="name"/>
        <saml:Attribute xsi:type="xsi:string" Name="spidCode"/>
        <saml:Attribute xsi:type="xsi:string" Name="fiscalNumber"/>
        <saml:Attribute xsi:type="xsi:string" Name="gender"/>
        <saml:Attribute xsi:type="xsi:string" Name="dateOfBirth"/>
        <saml:Attribute xsi:type="xsi:string" Name="placeOfBirth"/>
        <saml:Attribute xsi:type="xsi:string" Name="companyName"/>
        <saml:Attribute xsi:type="xsi:string" Name="registeredOffice"/>
        <saml:Attribute xsi:type="xsi:string" Name="ivaCode"/>
        <saml:Attribute xsi:type="xsi:string" Name="idCard"/>
        <saml:Attribute xsi:type="xsi:string" Name="mobilePhone"/>
        <saml:Attribute xsi:type="xsi:string" Name="email"/>
        <saml:Attribute xsi:type="xsi:string" Name="address"/>
        <saml:Attribute xsi:type="xsi:string" Name="digitalAddress"/>
    </md:IDPSSODescriptor>
    <md:Organization>
        <md:OrganizationName xml:lang="it">SPID Identity Provider</md:OrganizationName>
        <md:OrganizationDisplayName xml:lang="it">SPID Identity Provider</md:OrganizationDisplayName>
        <md:OrganizationURL xml:lang="it">https://spid.identityprovider.it</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="billing">
        <md:Extensions>
            <fpa:CessionarioCommittente>
            <fpa:DatiAnagrafici>
            <fpa:IdFiscaleIVA>
                <fpa:IdPaese>IT</fpa:IdPaese>
                <fpa:IdCodice>983745349857</fpa:IdCodice>
            </fpa:IdFiscaleIVA>
            <fpa:Anagrafica>
                <fpa:Denominazione>Destinatario Fatturazione</fpa:Denominazione>
            </fpa:Anagrafica>
            </fpa:DatiAnagrafici>
            <fpa:Sede>
                <fpa:Indirizzo>via tante cose</fpa:Indirizzo>
                <fpa:NumeroCivico>12</fpa:NumeroCivico>
                <fpa:CAP>87100</fpa:CAP>
                <fpa:Comune>Cosenza</fpa:Comune>
                <fpa:Provincia>CS</fpa:Provincia>
                <fpa:Nazione>IT</fpa:Nazione>
            </fpa:Sede>
            </fpa:CessionarioCommittente>
        </md:Extensions>
        <md:Company>example s.p.a.</md:Company>
        <md:EmailAddress>info@example.org</md:EmailAddress>
        <md:TelephoneNumber>+39 84756344785</md:TelephoneNumber>
    </md:ContactPerson>
</md:EntityDescriptor>

Service Provider¶

Le caratteristiche del Service Provider devono essere definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettare le condizioni di seguito indicate:

• Nell’elemento <EntityDescriptor> deve essere presente il seguente attributo:

  • entityID (1 occorrenza) - Attributo valorizzato con l’EntityID, così come riportato nell’estensione uri del certificato elettronico del SP. In caso il SP svolga più attività - come ad esempio quella di SP pubblico e di SP privato - si dota di metadata saml differenti, ciascuno con un diverso EntityID.

• Deve essere presente l’elemento <KeyDescriptor> contenenete il certificato della corrispondente chiave pubblica dell’entità, utile per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAML-Metadata, par. 2.4.1.1);

• Deve essere presente l’elemento <Signature> riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore;

• Deve essere presente un solo elemento <SPSSODescriptor> riportante i seguenti attributi:

  • protocolSupportEnumeration: che enumera, separati da uno spazio, gli URI associati ai protocolli supportati dall’entità (poiché si tratta di un’entità SAML 2.0, deve indicare almeno il valore del relativo protocollo: urn:oasis:names:tc:SAML:2.0:protocol);
  • AuthnRequestSigned: valorizzato true attributo con valore booleano che esprime il requisito che le richieste di autenticazione inviate dal Service Provider siano firmate;

• Deve essere presente almeno un elemento <AssertionConsumerService> indicante il servizio (in termini di URL e relativo binding HTTP-POST) a cui contattare il Service Provider per l’invio di risposte SAML, riportante i seguenti attributi:

  • index che può assumere valori unsigned;
  • Binding posto al valore urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST;
  • Location URL endpoint del servizio per la ricezione delle risposte;

  In particolare il primo di questi elementi (o l’unico elemento riportato) deve obbligatoriamente riportare:

  • l’attributo index posto al valore 0;
  • l’attributo isDefault posto al valore true;

• Deve essere presente almeno un elemento <SingleLogoutService> indicante l’indirizzo del SingleLogoutService e riportante i seguenti attributi:

  • Location URL endpoint del servizio per la ricezione delle richieste di Single Logout;

  • Binding che può assumere uno dei valori

    • urn:oasis:names:tc:SAML:2.0:bindings:SOAP
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
    • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST

  ed opzionalmente l’attributo:

  • ResponseLocation, URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout.

• Organization (1 occorrenza) — Contiene vari tag, ciascuno dei quali ripetuto almeno una volta valorizzato in lingua italiana, più occorrenze facoltative localizzanti il medesimo nome in ulteriori lingue (identificate mediante l’attributo xml:lang, obbligatoriamente presente in tutti i tag figli):

  • OrganizationName (1 o più occorrenze) — Denominazione – completa e per esteso e con il corretto uso di minuscole, maiuscole, lettere accentate e altri segni diacritici – del SP, così come riportata nell’estensione organizationName del certificato elettronico del SP (esempio: “Agenzia per l’Italia Digitale”).
  • OrganizationDisplayName (1 o più occorrenze) — Denominazione del SP, eventualmente in forma abbreviata (senza esplicitare gli eventuali acronimi) con il corretto utilizzo delle minuscole e maiuscole (esempio: “AgID”). Durante la fase di autenticazione, gli IdP avvisano l’utente dell’invio degli attributi al SP, visualizzando il valore di questo tag per indicare il soggetto richiedente.
  • OrganizationURL (1 o più occorrenze) — Contiene l’ url di una pagina del sito web del SP relativa al servizio di autenticazione o ai servizi accessibili tramite essa, i cui contenuti sono localizzati nella lingua specificata dal proprio attributo xml:lang.

• ContactPerson (1 o 2 occorrenze) — Tag utilizzato per veicolare le informazioni per contattare il soggetto cui il metadata afferisce. Ogni occorrenza è dotata dei seguenti attributi:

  • contactType — L’occorrenza obbligatoria di ContactPerson è valorizzata con other; l’ulteriore occorrenza, obbligatoria per i soli SP privati, è valorizzata con billing.

L’occorrenza di ContactPerson con l’attributo contactType valorizzato come other contiene i seguenti tag (namespace md):

• Extensions (1 occorrenza obbligatoria) — Contenente almeno uno dei seguenti tag (tutti con namespace spid):

  1. IPACode — Presente solo per il SP pubblico, è valorizzato con il codice ipa dell’Ente.
  2. VATNumber — Obbligatorio per il SP privato dotato di partita iva (altrimenti facoltativo), è valorizzato comprensivo del codice ISO 3166-1 α-2 del Paese (senza spazi).
  3. FiscalCode — Obbligatorio per il SP privato non dotato di partita iva (altrimenti facoltativo), è valorizzato con il codice fiscale del SP.
  4. Public — Tag vuoto, obbligatorio per il SP pubblico o,

  in alternativa,

• Private — Tag vuoto, obbligatorio per il SP privato.

• Company (0 o 1 occorrenze) — Se presente, è valorizzato come il tag OrganizationName contenuto nel tag Organization.
• EmailAddress (1 occorrenza, obbligatorio) — Contiene l’indirizzo di posta elettronica per contattare il SP. Non deve trattarsi di un indirizzo riferibile direttamente ad una persona fisica.
• TelephoneNumber (0 o 1 occorrenze) — Contiene il numero di telefono, per contattare il SP; senza spazi e comprensivo del prefisso internazionale (esempio: “+39” per l’Italia).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

<md:EntityDescriptor
       entityID="https://entityID.unico/dell/SP"
       ID="_uniqueID"
       xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
       xmlns:spid="https://spid.gov.it/saml-extensions">
    <md:Organization>
        <md:OrganizationName xml:lang="it">
            Denominazione Completa dell'Organizzazione s.r.l.
        </md:OrganizationName>
        <md:OrganizationDisplayName xml:lang="it">
            Organizzazione
        </md:OrganizationDisplayName>
        <md:OrganizationURL xml:lang="it">
            https://organizzazione.com/it
        </md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="other">
        <md:Extensions>
            <spid:VATNumber>IT12345678901</spid:VATNumber>
            <spid:FiscalCode>XYZABCAAMGGJ000W</spid:FiscalCode>
            <spid:Private/>
        </md:Extensions>
        <md:EmailAddress>spid@organizzazione.com</md:EmailAddress>
        <md:TelephoneNumber>+390123456789</md:TelephoneNumber>
    </md:ContactPerson>
    <md:ContactPerson contactType="billing">
        <md:Extensions 
               xmlns:fpa="https://spid.gov.it/invoicing-extensions">
            <fpa:CessionarioCommittente>
                <fpa:DatiAnagrafici>
                    <fpa:IdFiscaleIVA>
                        <fpa:IdPaese>IT</fpa:IdPaese>
                        <fpa:IdCodice>02468135791</fpa:IdCodice>
                    </fpa:IdFiscaleIVA>
                    <fpa:Anagrafica>
			           <fpa:Denominazione>
                            Destinatario_Fatturazione
			           </fpa:Denominazione> 
                    </fpa:Anagrafica>
                </fpa:DatiAnagrafici>
                <fpa:Sede>
		             <fpa:Indirizzo>via [...]</fpa:Indirizzo>
		             <fpa:NumeroCivico>99</fpa:NumeroCivico>
		             <fpa:CAP>12345</ fpa:CAP>
		             <fpa:Comune>nome_citta</fpa:Comune>
		             <fpa:Provincia>XY</fpa:Provincia>
                    <fpa:Nazione>IT</fpa:Nazione>
                </fpa:Sede>
            </fpa:CessionarioCommittente>
        </md:Extensions>
        <md:Company>Destinatario_Fatturazione</md:Company>
        <md:EmailAddress>email@fatturazione.it</md:EmailAddress>
        <md:TelephoneNumber>telefono_fatture</md:TelephoneNumber>
    </md:ContactPerson>
 </md:EntityDescriptor>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:spid="https://spid.gov.it/saml-extensions"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    entityID="https://spid.serviceprovider.it"
    ID="_0j40cj0848d8e3jncjdjss...">
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        [...]
    </ds:Signature>
    <md:SPSSODescriptor
        protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
        AuthnRequestsSigned="true"
        WantAssertionsSigned="true">
        <md:KeyDescriptor use="signing">
            [...]
        </md:KeyDescriptor>
        <SingleLogoutService
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://spid.serviceprovider.it/slo-location"
            ResponseLocation="https://spid.serviceprovider.it/slo-location"/>
        <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
        <md:AssertionConsumerService
            index="0" isDefault="true"
            Location="https://spid.serviceprovider.it/sso-location"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:AssertionConsumerService
            index="1"
            Location="https://spidSP.serviceProvider.it/sso-location"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
        <md:AttributeConsumingService index="0">
            <md:ServiceName xml:lang="it">Set 0</md:ServiceName>
            <md:RequestedAttribute Name="name"/>
            <md:RequestedAttribute Name="familyName"/>
            <md:RequestedAttribute Name="fiscalNumber"/>
            <md:RequestedAttribute Name="email"/>
        </md:AttributeConsumingService>
            <md:AttributeConsumingService index="1">
            <md:ServiceName xml:lang="it">Set 1</md:ServiceName>
            <md:RequestedAttribute Name="spidCode"/>
            <md:RequestedAttribute Name="fiscalNumber"/>
        </md:AttributeConsumingService>
    </md:SPSSODescriptor>
    <md:Organization>
        <OrganizationName xml:lang="it">Service provider</OrganizationName>
        <OrganizationDisplayName xml:lang="it">Nome service provider</OrganizationDisplayName>
        <OrganizationURL xml:lang="it">http://spid.serviceprovider.it</OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="other">
        <md:Extensions>
            <spid:VATNumber>IT12345678901</spid:VATNumber>
            <spid:FiscalCode>XYZABCAAMGGJ000W</spid:FiscalCode>
            <spid:Private/>
        </md:Extensions>
        <md:EmailAddress>tech-info@example.org</md:EmailAddress>
        <md:TelephoneNumber>+39 8472345634785</md:TelephoneNumber>
    </md:ContactPerson>
</md:EntityDescriptor>

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.

AuthnRequest¶

Il messaggio AuthnRequest è inviato dal Service Provider, per tramite dello User Agent, al SingleSignOnService dell’Identity Provider ed ha la funzione di avviare il flusso di autenticazione. Può essere inoltrato da un Service Provider all’Identity Provider usando il binding HTTP-Redirect o il binding HTTP-POST. Il messaggio deve essere conforme allo standard SAML v2.0 (cfr. [SAML-Core]) e rispettare le condizioni di seguito indicate.

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

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_4d38c302617b5bf98951e65b4cf304711e2166df20"
    Version="2.0"
    IssueInstant="2015-01-29T10:00:31Z"
    Destination="https://spid.identityprovider.it/redirect-Post-saml2sso"
    AssertionConsumerServiceURL="http://spid.serviceprovider.it"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    AttributeConsumingServiceIndex="1">
    <saml:Issuer
        NameQualifier="http://spid.serviceprovider.it"
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        http://spid.serviceprovider.it
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        [...]
    </ds:Signature>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    <samlp:RequestedAuthnContext Comparison="exact">
        <saml:AuthnContextClassRef>
            https://www.spid.gov.it/SpidL2
        </saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Response¶

La risposta inviata dall’Identity Provider al Service Provider può essere trasmessa solo tramite il binding HTTP-POST e deve avere le seguenti caratteristiche:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183

<samlp:Response Destination="https://that.spid.example.org/saml2/acs/post" ID="_5e728601-9ad4-4686-b269-81d107a8194a" InResponseTo="id-wr6bt7ZpfqiYVrqTd" IssueInstant="2021-02-04T15:41:59Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        http://localhost:8080
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#_5e728601-9ad4-4686-b269-81d107a8194a">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    ...
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
            ...
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    ...
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
       
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    
    <saml:Assertion ID="_bebbed6a-2f6c-43d9-b151-f214d0c61de0" IssueInstant="2021-02-04T15:41:59Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://that.spid.idp.example.org/metadata
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#_bebbed6a-2f6c-43d9-b151-f214d0c61de0">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        6V8qWljmWULO0C0OQit0DaylE+neFN9K8SXR2izWXpw=
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                ...
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        ...
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        
        <saml:Subject>
            <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://validator.spid.gov.it">
                    _655df4bc-b372-475e-906d-e71e4d7e98de
            </saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData InResponseTo="id-wr6bt7ZpfqiYVrqTd" NotOnOrAfter="2021-02-04T15:46:51Z" Recipient="https://that.spid.example.org/saml2/acs/post"/>
            </saml:SubjectConfirmation>
        </saml:Subject>
        
        <saml:Conditions NotBefore="2021-02-04T15:41:59Z" NotOnOrAfter="2021-02-04T15:46:51Z">
            <saml:AudienceRestriction>
                <saml:Audience>
                    http://that.spid.example.org/saml2/metadata
                </saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
         
        <saml:AuthnStatement AuthnInstant="2021-02-04T15:41:59Z" SessionIndex="_ec9c5b35-12dc-414d-ad09-5b4610934db8">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                    https://www.spid.gov.it/SpidL1
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
        
        <saml:AttributeStatement>

            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">                       
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>                                          
            <saml:Attribute Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    SpidValidator
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="familyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AgID
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="placeOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    Roma
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="countyOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    RM
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="dateOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:date">
                    2000-01-01
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="gender" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    M
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="companyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    Agenzia per l'Italia Digitale
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="registeredOffice" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    Via Listz 21 00144 Roma
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="fiscalNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    TINIT-GDASDV00A01H501J
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="ivaCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    VATIT-97735020584
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="idCard" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    CartaIdentità AA00000000 ComuneRoma 2018-01-01 2028-01-01
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="expirationDate" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:date">
                    2028-01-01
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="mobilePhone" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    +393331234567
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    spid.tech@agid.gov.it
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="address" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    Via Listz 21 00144 Roma
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="digitalAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    pec@pecagid.gov.it
                </saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>

</samlp:Response>

Gestione delle sessioni¶

Ai sensi dell’art 28 del regolamento Modalità attuative per la realizzazione dello SPID un gestore delle identità a completamento con esito positivo dell’autenticazione relativa al livello SPID 1 di un utente stabilisce per lo stesso utente una sessione finalizzata al processo di autenticazione. Nel corso di validità della sessione instaurata, il gestore delle identità può rilasciare ai fornitori di servizi, che fanno richiesta di autenticazione di livello SPID 1 per l’utente con il quale è stata stabilita la sessione, asserzioni di autenticazione basate sull’evento di autenticazione che ha dato origine alla sessione stessa. Ancora a i sensi dell’art 28 del regolamento Modalità attuative per la realizzazione dello SPID, per le richieste di autenticazione di livello SPID 2 e 3 non è prevista l’instaurazione di alcuna sessione, pertanto per ogni richiesta di questo tipo deve essere ripetuto l’evento di autenticazione. La sessione stabilita a seguito di un evento di autenticazione relativo al livello SPID 1 è denominata, per chiarezza di esposizione, sessione di autenticazione per distinguerla dalla sessione che un fornitore di servizi può instaurare con l’utente al fine dell’erogazione di un particolare servizio richiesto, denominata a sua volta sessione individuale.

La relazione esistente tra la sessione di autenticazione, mantenuta dal gestore dell’identità per un dato utente, e le sessioni individuali gestite per lo stesso utente dai fornitori di servizi stabilite sullo stesso evento di autenticazione che ha dato origine alla sessione di autenticazione, costituisce, in senso logico, una sessione distribuita che denominiamo sessione globale. Il diagramma di stato riportato in figura 1 specifica il comportamento che deve assumere il gestore delle identità per la gestione della sessione di autenticazione relativa ad un dato utente a fronte delle diverse richieste che possono essere presentate dai fornitori di servizi relativamente allo stesso utente.

L’evoluzione dello stato associato alla sessione di autenticazione deve rispettare le seguenti regole:

1. l’instaurazione di una sessione di autenticazione per un determinato utente avviene al completamento con esito positivo di una richiesta di autenticazione di livello SPID 1 da parte di un fornitore di servizi - evento di autenticazione andato a buon fine con contestuale assenso al trasferimento delle informazioni richieste -. Il fornitore di servizi che ha effettuato la richiesta entra a far parte della sessione globale;

2. le richieste di autenticazione per i livelli SPID 2 e SPID3 per un dato utente, non devono influenzare il regime di sessione per esso vigente. In particolare, se le richieste dovessero pervenire in presenza di una sessione di autenticazione relativa all’utente questa non deve essere in nessun caso chiusa; viceversa, se le richieste dovessero giungere in assenza di una sessione di autenticazione relativa all’utente questa non deve essere in nessun caso creata. Il fornitore di servizi che ha effettuato la richiesta non entra a far parte della sessione globale relativa all’utente qualora questa esistesse;

3. le richieste di autenticazione di livello SPID1 per un dato utente successive all’instaurazione di una sessione di autenticazione per lo stesso utente, qualunque sia il loro esito, non devono incidere sul perdurare della sessione stessa. Il mancato assenso da parte dell’utente al trasferimento delle informazioni richieste dal fornitore di servizi determina il fallimento della richiesta ma non deve produrre conseguenze sulla vigente sessione di autenticazione né sulla sessione globale; ovvero, in merito a quest’ultima, il mancato assenso non deve comportare:

   • l’esclusione dalla sessione globale del fornitore di servizi che opera la richiesta se questo fosse già coinvolto nella stessa sessione globale per una precedente richiesta andata a buon fine;
   • l’inclusione nella sessione globale del fornitore di servizi nel caso questo non fosse ancora coinvolto nella stessa sessione globale per una precedente richiesta andata a buon fine.

   L’assenso da parte dell’utente al trasferimento delle informazioni determina il successo della richiesta ed il coinvolgimento del fornitore di servizi nella sessione globale relativa all’utente, se lo stesso fornitore di servizi non ne facesse già parte per via di una precedente richiesta da esso effettuata ed andata a buon fine.

4. L’evento di Single Logout consiste nella chiusura della sessione di autenticazione e di tutte le sessioni individuali messe tra loro in relazione dalla sessione globale. Tale chiusura avviene su espressa richiesta dell’utente presso il gestore dell’identità o presso uno dei fornitori di servizi. La modalità prevista in SPID per il processo di Single Logout è quella definita dal SAML Single Logout Profile (cfr.[SAML-profiles] sez. 4.4). L’insieme dei fornitori di servizi che entrano a far parte della sessione globale, necessario alla corretta gestione del Single Logout Profile è popolato dinamicamente dal gestore delle identità, applicando i criteri espressi nei precedenti punti a), b, c). Il processo di Single Logout necessita per andare a buon fine del corretto comportamento di tutti i fornitori di servizio coinvolti nella sessione globale secondo quanto previsto dal suddetto Single Logout Profile. Se qualcuno di questi fornitori di servizi non rispetta il comportamento previsto dal Single Logout Profile, il processo non potrà essere concluso con successo e il Single Logout sarà perciò degradato a partial logout. Il partial logout, pur non dando garanzia che tutte le sessioni individuali vigenti presso i fornitori di servizio coinvolti nella sessione globale siano effettivamente chiuse, deve comunque assicurare la chiusura della sessione di autenticazione e, qualora la richiesta di Single Logout venga fatta presso un fornitore dei servizi, della sessione individuale mantenuta dallo stesso fornitore dei servizi presso cui viene operata la richiesta.

5. La sessione di autenticazione può essere chiusa ad opera del gestore dell’identità allo scadere del timeout associato alla sessione stessa o su richiesta operata dall’utente presso lo stesso gestore dell’identità. Con la chiusura della sessione di autenticazione viene meno la relazione che lega la sessione di autenticazione stessa con le sessioni individuali stabilite sulla base di quest’ultima e di conseguenza la sessione globale decade. Una eventuale richiesta di Single Logout relativa ad una sessione globale in precedenza venuta meno a seguito di una chiusura della sessione di autenticazione si risolve in una immediata notifica di partial logout, presentata dal gestore dell’identità al fornitore di servizi presso cui ne è stata fatta richiesta.

I gestori delle identità dovranno mettere a disposizioni dell’utente funzionalità per la richiesta di Single Logout o per la chiusura della sessione di autenticazione.

LogoutRequest¶

Il messaggio di LogoutRequest deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:

LogoutResponse¶

Il messaggio di LogoutResponse deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:

Binding¶

Per il trasporto dei messaggi di LogoutRequest e del relativo LogoutResponse. possono essere utilizzati binding di tipo sincrono (SOAP) o di tipo asincrono (http-redirect o http-POST). Nel caso di uso di binding http-redirect o http-POST, si faccia riferimento a quanto già specificato nel documento SPID Regole tecniche rispettivamente ai paragrafi al paragrafo 1.2.2.1 e 1.2.2.2 per le richieste di autenticazione (SSO Profile), tenendo presente che i messaggi di LogoutRequest e LogoutResponse devono essere veicolati rispettivamente nei previsti parametri/hidden form control denominati SAMLRequest e SAMLResponse. Per il binding SOAP si faccia riferimento a quanto già specificato sempre nel documento SPID Regole tecniche al paragrafo 2.2.3. Gli scambi dovranno avvenire su canale sicuro realizzato mediante l’impiego di TLS nella versione più recente disponibile.

Contenuti del Registro¶

Il federation registry contiene la lista delle entità che hanno superato il processo di accreditamento e quindi facenti parte della federazione SPID. Le informazioni contenute nel registro per ciascuna delle suddette entità sono le seguenti:

• AuthorityInfo: entry del Registro relativa ad una entità, a sua volta costituita da:

  • EntityId: identificatore SAML dell’entità;
  • Soggetto: denominazione del soggetto a cui afferisce l’entità della federazione;
  • EntityType: tipo di entità (Identity Provider, Attribute Authority, Service Provider);
  • MetadataProviderURL: l’URL del servizio di reperimento metadati;
  • AttributeList: elenco di attributi qualificati certificabili da una entità di tipo Attribute Authority.

Il federation registry viene popolato dall’Agenzia per l’Italia Digitale a seguito del processo di stipula delle convenzioni e aggiornata dalla stessa Agenzia nel corso delle attività legate alla gestione delle convenzioni e della vigilanza sui soggetti del circuito SPID. Il contenuto informativo della federation registry è in fruizione a tutte le entità appartenenti al circuito SPID ai fini della verifica della sussistenza di relazioni di trust nei confronti di entità terze (IdP, AA, SP) e del reperimento delle informazioni associate alla alle stesse. Il Discovery Service può anch’esso accedere al federation registry per utilizzarne i contenuti ai fini dell’attività di discovering.

Accesso al Registro¶

Accesso al Registro in modalità LDAP¶

Identity Provider¶

Ai fini della tracciatura l’Identity Provider dovrà mantenere un Registro delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la tripla composta dell’identificativo dell’identità digitale (spidCode) interessata dalla transazione, dalla <AuthnRequest> e della relativa <Response>.

Al fine di consentire una facile ricerca e consultazione dei dati di tracciature potrebbe essere opportuno memorizzare in ogni record informazioni direttamente estratte dai suddetti messaggi in formato SAML. A titolo esemplificativo e non esaustivo le informazioni presenti in un record del registro potrebbero essere le seguenti:

• SpidCode
• <AuthnRequest>
• <Response>
• AuthnReq_ID
• AuthnReq_ IssueInstant
• AuthnReq_ Issuer
• Resp_ID
• Resp_IssueInstant
• Resp_Issuer
• Assertion_ID
• Assertion_subject
• Assertion_subject_NameQualifier

Service Provider¶

Il comma 2 dell’articolo 13 del DPCM obbliga i fornitori di servizi (Service Provider) alla conservazione per ventiquattro mesi delle informazioni necessarie a imputare alle singole identità digitali le operazioni effettuate sui propri sistemi.

A tal fine un Service provider dovrà mantenere un Registro delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la coppia dalla <AuthnRequest> e della relativa <Response>.

Al fine di consentire una facile ricerca e consultazione dei dati di tracciature potrebbe essere opportuno memorizzare in ogni record informazioni direttamente estratte dai suddetti messaggi in formato SAML. A titolo esemplificativo e non esaustivo le informazioni presenti in un record del registro potrebbero essere le seguenti:

• <AuthnRequest>
• <Response>
• AuthnReq_ID
• AuthnReq_IssueInstant
• Resp_ID
• Resp_IssueInstant
• Resp_Issuer
• Assertion_ID
• Assertion_subject
• Assertion_subject_NameQualifier

Autenticazione corretta¶

Anomalie del sistema¶

Anomalie delle richieste¶

Anomalie derivanti dall’utente¶