Docs Italia beta

Documenti pubblici, digitali.

3. Protocolli di comunicazione

Terminata la fase di federazione tramite lo scambio dei metadata opportunamente predisposti come da specifiche riportate nella precedente sezione, il Service Provider viene aggiunto nella trusted list dell’Identity Provider ed é quindi possibile lo scambio dei messaggi previsto dal protocollo SAML SSO. Tale protocollo viene avviato al momento in cui l’utente esprime la volontà di accedere al servizio cliccando il tasto «Entra con CIE» nella pagina html del Service Provider. Quest’ultimo prepara di conseguenza una richiesta di autenticazione (<AuthnRequest>) che inoltra all’Identity Provider al quale l’utente viene reindirizzato per effettuare l’autenticazione tramite la propria CIE. La componente server dell’Identity Provider (CieID Server) invita l’utente a avvicinare la propria CIE sul lettore avviando automaticamente il processo di autenticazione mediante la CIE. L’utente deve, quindi, inserire la seconda metà del PIN e confermare.

Processo di autenticazione del CieID Server

Fig. 3.1 Processo di autenticazione del CieID Server

Terminato il processo di autenticazione il server CieID mostra una pagina contenente gli attributi desunti dal certificato digitale a bordo della carta. L’utente, informato degli attributi che si stanno per inviare al servizio, prosegue con l’operazione e viene reindirizzato nuovamente sul sito del Service Provider, con un’asserzione (<Response>) firmata dall’Identity Provider contenente gli attributi richiesti (nome, cognome, data di nascita e codice fiscale).

Nota

All’interno dello schema Entra con CIE solo il Single Sign-On viene gestisto tramite protocollo SAML che prevede di tue tipologie di messaggi:

  • Richiesta di autenticazione: <AuthnRequest>;
  • Risposta di autenticazione: <Response>.

La gestione del logout, attualmente, non supporta il procollo SAML, ma viene gestite mediante un meccanismo di Simple Logout che provvede all’eliminazione della sessione di autenticazione dell’Identity Provider. Pertanto, pur accettando le richieste SAML di Single Logout, l’IdP server CieID non restituisce alcuna risposta SAML.

3.1. Richiesta di autenticazione SAML

La richiesta di autenticazione («request») è inviata dal Service Provider attraverso il browser dell’utente al SingleSignOnService dell’Identity Provider. Il messaggio contenuto in essa deve essere conforme allo standard SAML v2.0 (cfr. Assertions and Protocols for the OASIS SAML V2.0).

L’elemento <AuthnRequest> costituisce il contenitore del messaggio e deve avere i seguenti attributi:

  • Destination rappresenta un URL in https che indica l’indirizzo dell’Identity Provider a cui è inviata la richiesta e deve coincidere con uno degli attributi Location presenti nel tag SingleSignOnService riportato nel metadata dell’IdP e relativo al particolare binding utilizzato in fase di richiesta (cfr. Modalitá di trasmissione dei messaggi per ulteriori dettagli). L’Identity Provider verifica tale riferimento e, in caso di esito negativo, la richiesta viene scartata.
  • AttributeConsumingServiceIndex riportante un indice posizionale in riferimento alla struttura <AttributeConsumingService> presente nei metadata del Service Provider. A tal proposito si ricorda che gli attributi richiesti nel metadata devono contenere il Minimum Dataset eIDAS.
  • AssertionConsumerServiceURL indica la URL a cui inviare il messaggio di risposta alla richiesta di autenticazione (l’indirizzo deve coincidere con quello del servizio riportato dall’elemento <AssertionConsumingService> presente nei metadata del Service Provider);
  • ProtocolBinding identifica il tipo di binding e deve essere valorizzato con urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST.
  • ForceAuthn è sempre valorizzato con true in quanto si richiede un’autenticazione con massimo livello di sicurezza.
  • IssueInstant indica l’istante di emissione della richiesta, in formato UTC (p.es. AAAA-MM-GGThh:mm:ss.sssZ)
  • ID univoco basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità).
  • Version coerentemente con la versione di SAML adottata; attualmente la 2.0.

Nota

  • In alternativa, è ammesso l’uso dell’attributo AssertionConsumerServiceIndex al posto degli attributi AssertionConsumerServiceURL e ProtocolBinding.
  • L’attributo IsPassive non deve essere presente.
  • L’attributo Destination deve essere valorizzato in accordo con lo standard SAML e non secondo quanto prescitto dalle Regole Tecniche SPID.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  AttributeConsumingServiceIndex="0"
  AssertionConsumerServiceIndex="0"
  Destination="https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/Redirect/SSO"
  ForceAuthn="true"
  IssueInstant="2020-10-29T12:51:36.123Z"
  ID="..."
  Version="2.0">
    [...]
</samlp:AuthnRequest>

Gli elementi che devono essere presenti all’interno della <AuthnRequest> sono:

  • <saml:Issuer>: identifica in maniera univoca il Service Provider. L’elemento deve essere valorizzato come l’attributo entityID riportato nel corrispondente metadata del Service Provider. Prevede, inoltre, i seguenti attributi opzionali:
  • NameQualifier, dominio a cui afferisce il soggetto che sta effettuando la richiesta di autenticazione e valorizzato come URL riconducibile al Service Provider;
  • Format, se presente deve essere valorizzato con la stringa urn:oasis:names:tc:SAML:2.0:nameid-format:entity.
  • <NameIDPolicy> avente l’attributo Format valorizzato con la stringa urn:oasis:names:tc:SAML:2.0:nameid-format:transient, mentre invece non deve essere presente l’attributo AllowCreate.

  • <RequestedAuthnContext> (ne è presente una sola occorrenza) specifica i requisiti del contesto di autenticazione di statement di autenticazione restituite in risposta a una richiesta. Esso è valorizzato come segue:

    • mediante l’attributo Comparison, che specifica il metodo di confronto utilizzato per valutare le classi o gli statement di contesto richiesti e può essere valorizzato soltanto come exact (default), ovvero minimum;

    • contenente l’elemento <RequestedAuthnContext>, contiene a sua volta l’elemento <saml:AuthnContextClassRef>, valorizzato con uno dei seguenti valori:

      • https://www.spid.gov.it/SpidL1
      • https://www.spid.gov.it/SpidL2
      • https://www.spid.gov.it/SpidL3

Lo schema di autenticazione «Entra con CIE», nell’ottica di agevolare gli sviluppi implementativi da parte dei Service Provider che giá hanno aderito al Sistema Pubblico di Identità Digitale (SPID), richiede la valorizzazione di tale elemento con una delle suddette stringhe (corrispondenti ai tre livelli di affidabilità dello SPID), sebbene il livello di affidabilità dello schema CIE è sempre analogo al quello massimo previsto per tutti gli schemi di identificazione elettronica a livello europeo (analogo anche al Livello 3 di SPID). Pertanto, per consentire al cittadino di autenticarsi sia a servizi accessibili tramite CIE, che a quelli accessibili tramite qualunque livello di sicurezza SPID, le possibili combinazioni di valori dell’elemento <RequestedAuthnContextClassRef> e dell’attributo-antenato Comparison sono, rispettivamente:

  • autenticazione con CIE ovvero con SPID di Livello 3: https://www.spid.gov.it/SpidL3 e, equivalentemente, exact ovvero minimum;
  • autenticazione con CIE ovvero con SPID di Livelli 2 o 3: https://www.spid.gov.it/SpidL2 e minimum;
  • autenticazione con CIE ovvero con SPID (qualunque Livello): https://www.spid.gov.it/SpidL1 e minimum;

Nota

  • Dipendentemente dal tipo di binding utilizzato per inviare la richiesta di autenticazione può essere presente o meno l’elemento <Signature> (obbligatorio in caso di binding HTTP POST), che contiene il sigillo elettronico creato dal Service Provider sulla propia request. Per maggiori dettagli, si veda il capitolo relativo all”infrastruttura a chiave pubblica.
  • Non sono presenti gli elementi <RequesterID> e <Scoping>.

3.1.1. Esempio di request SAML

Si noti che l’elemento XML <Signature> nel seguente esempio va inserito solo nel caso di utilizzo del binding HTTP POST; in caso di binding HTTP Redirect, il sigillo elettronico è immerso invece nel parametro Signature della query string. Per ulteriori informazioni si faccia riferimento al capitolo sull”infrastruttura a chiave pubblica.

 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
<samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  AttributeConsumingServiceIndex="0"
  AssertionConsumerServiceURL=" [...] "
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Destination="https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/POST/SSO"
  ForceAuthn="true"
  ID="..."
  IssueInstant="2020-11-02T09:01:25Z" Version="2.0">
    <saml:Issuer NameQualifier="https://service_provide_entityID">
        https://service_provider_entityID
    </saml:Issuer>
    <ds:Signature>
        <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="RIFERIMENTO ALL'ID DELL'ATTRIBUTO">
                <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:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    <samlp:RequestedAuthnContext Comparison="minimum">
        <saml:AuthnContextClassRef>https://www.spid.gov.it/SpidL3</saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

3.2. Risposta di autenticazione SAML

Al termine della challenge mediante la CIE, effettuata dal server CieID dell’Identity Provider, quest’ultimo invia un messaggio di risposta («response») al Service Provider. L’elemento <Response> costituisce la radice del messaggio e contiene i seguenti attributi:

  • Destination: URL del Service Provider a cui è inviata la risposta; coincide con la URL riportata nel metadata cosí come specificato dall’attributo location presente nell’elemento <AssertionConsumerService>. Il Service Provider deve verificare il riferimento URI e, in caso di esito negativo, deve scartare la risposta;
  • ID: identificatore univoco basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  • InResponseTo: riferimento all’ID della richiesta a cui si risponde;
  • IssueInstant: indica l’istante di emissione della richiesta, in formato UTC (AAAA-MM-GGThh:mm:ss.sssZ);
  • Version: riferimento alla versione SAML (2.0) utilizzata dallo schema Entra con CIE.

Gli elementi contenuti nella <Response> (tutti dichiarati con il corretto uso dei namespace XML) sono:

  • <Issuer>: in maniera analoga a quanto previsto per la request, tale campo indica l’EntityID del soggetto che effettua l’autenticazione (cioè l’Identity Provider stesso) e coincide perciò con l’attributo entityID del metadata dell’IdP.

  • <Signature>: contiene il sigillo elettronico apposto sulla request dell’Identity Provider. Per ulteriori informazioni si faccia riferimento al capitolo sull”infrastruttura a chiave pubblica.

  • <Status>: indica l’esito della richiesta di autenticazione e in particolare prevede l’elemento <StatusCode> che riporta la codifica di stato SAML attraverso l’attributo Value, valorizzato come:

    • urn:oasis:names:tc:SAML:2.0:status:Success, nel caso di autenticazione effettuata con successo;
    • in caso di errori, é possibile visualizzare gli attributi <StatusMessage> e <StatusDetail> per maggiori dettagli sull’errore ricevuto.
  • <Assertion>: costituisce l’elemento piú importante che attesta l’avvenuta autenticazione e contiene gli attributi dell’utente che ha richiesto l’accesso al servizio. Contiene almeno un elemento <AuthnStatement> nel quale sono riportati i dati dell’utente richiesti dal Service Provider. Nel caso l’Identity Provider abbia riscontrato un errore nella gestione della richiesta di autenticazione l’elemento <Assertion> non é presente.

3.2.1. Esempio di response SAML

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  Destination="https://service_provide_assertion_consumer"
  InResponseTo="..."
  IssueInstant="2020-10-29T11:36:02.708Z"
  ID="..."
  Version="2.0">
    <saml:Issuer>
        https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/POST/SSO
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        [...]
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <saml:Assertion>
        [...]
    </saml:Assertion>
</samlp:Response>

3.2.2. L’elemento <saml:Assertion>

Nell’elemento <Assertion> devono essere presenti i seguenti attributi:

  • ID: identificatore univoco basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  • IssueInstant: indica l’istante di emissione della richiesta, in formato UTC (AAAA-MM-GGThh:mm:ss.sssZ);
  • Version: riferimento alla versione SAML (2.0) utilizzata dallo schema Entra con CIE.

Gli attributi contenuti nella <Assertion> sono i seguenti:

  • <Issuer>: valorizzato coerentemente con l”EntityID (attributo entityID) presente nei corrispondenti metadata dell’Identity Provider.

  • <Signature>: contiene il sigillo elettronico apposto sull’asserzione dell’Identity Provider. Per ulteriori informazioni si faccia riferimento al capitolo sull”infrastruttura a chiave pubblica.

  • <Subject>: serve a qualificare il Service Provider che ha richiesto l’autenticazione. In particolare, contiene due elementi:

    • <NameID>: riferimento all’identificativo del SP e contenente principalmente le informazioni che qulificano l’IdP (NameQualifier) e il SP (SPNameQualifier)

    • <SubjectConfirmation>: riporta l’attributo Method valorizzato con la stringa urn:oasis:names:tc:SAML:2.0:cm:bearer. Tale elemento contiene inoltre l’elemento <SubjectConfirmationData> riportante gli attributi:

      • Recipient coerente con l”AssertionConsumerServiceURL relativa al servizio per cui è stata emessa l’asserzione e l’attributo;
      • NotOnOrAfter indica per quanto tempo l’asserzione puó ritenersi legata al subject. L’asserzione puó, tuttavia, essere valida per un tempo piú lungo, ma é necessario creare una sessione entro questo intervallo di tempo (per maggiori dettagli consultare la sezione 4.1.4.3. del Profilo Web SSO). Tale intervallo di tempo deve rientrare necessariamente nell’intervallo di tempo riportato nell’elemento <Conditions>;
      • InResponseTo il cui valore deve fare riferimento all’ID della richiesta;
      • Address, facoltativamente presente, contiene un identificativo univoco (ma non riconducibile a informazioni tecnico-implementative) dello specifico server CieID che ha tecnicamente effettuato l’autenticazione;
  • <Conditions>: contenente gli attributi NotBefore e NotOnOrAfter che rappresentano le condizioni di validitá dell’asserzione. Inoltre é presente l’elemento <AudienceRestriction> riportante a sua volta l’elemento <Audience>, valorizzato con l”EntityID del Service Provider per il quale l’asserzione è emessa.

  • <AuthnStatement>: oltre alle informazioni riguardanti il riferimento alla sessione (SessionIndex), l’istante temporale di autenticazione dell’utente (AuthnInstant). Contiene a sua volta l’elemento AuthnContext e il sotto-elemento <AuthnContextClassRef> valorizzato con il livello di affidabilità associato all’autenticazione con CIE.

  • <AttributeStatement>: rappresenta la struttura nella quale sono riportati gli attributi relativi all’utente, così come richiesti dell’omologo elemento della request SAML.

In particolare, a fronte della richiesta del eIDAS Minimum Data Set l’asserzione contiene quattro elementi di tipo <Attribute> (ciascuno contenente l’attributo Name valorizzato come segue e l’attributo NameFormat valorizzato con urn:oasis:names:tc:SAML:2.0:attrname-forma):

  • name (di tipo xs:string), valorizzato con il nome del soggetto;
  • familyName (di tipo xs:string), valorizzato con il cognome del soggetto;
  • dateOfBirth (di tipo xs:string) data di nascita nel formato YYYY-MM-GG;
  • fiscalNumber (di tipo xs:string), valorizzato con il codice fiscale nel formato TINIT-<CODICE FISCALE>.

Nota

L’elemento <AuthnContextClassRef> discendente dell’elemento <AuthnStatement> è sempre valorizzato con https://www.spid.gov.it/SpidL3 poiché la CIE fornisce un livello di affidabilità massimo a livello europeo, corispondente al Livello 3 del Sitema Pubblico dell’Identità Digitale (SPID). Per favorire l’interoperabilitá con SPID da parte dei Service Provider e minimizzare quindi l’impatto nella gestione implementativa delle risposte SAML per i SP che intendono aderere ad entrambi gli schemi di autenticazione, si restituisce dunque una classe analoa a quella usata dagli Identity Provider SPID nelle response associate ad autenticazioni avvenute con Livello 3.

Nota

Con riferimento alla compatibilità con SPID si riporta quanto segue:

  • L’attributo Format dell’elemento <samlp:Issuer> non è presente;
  • L’elemento <saml:AuthnContextClassRef> è valorizzato sempre con il valore https://www.spid.gov.it/SpidL3;
  • Gli attributi inviati in risposta alla richiesta di autenticazione corrispondono sempre al Minimum Dataset eIDAS e non prevedono, nella versione attuale, l’invio di ulteriori attributi quali ad esempio lo spidCode.

3.2.3. Verifica della <Response>

Alla ricezione della <Response> qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve eseguire le seguenti verifiche:

  • Controllo delle firme presenti all’interno dell”<Assertion> e della <Response>

  • Verifica che nell’elemento <SubjectConfirmationData>

    • l’attributo Recipient coincida con la AssertionConsumerServiceURL a cui la <Response> è pervenuta
    • l’attributo NotOnOrAfter non sia scaduto
    • l’attributo InResponseTo si riferisca correttamente all’ID della <AuthnRequest> di richiesta

Nota

É, inoltre, a carico del Service Provider garantire che le asserzioni non vengano ripresentate, mantenendo il set di identificatori di richiesta (ID) usati come per le <AuthnRequest> per tutta la durata di tempo per cui l’asserzione risulta essere valida in base dell’attributo NotOnOrAfter dell’elemento <SubjectConfirmationData> presente nell’asserzione stessa.

3.2.4. Esempio di <saml:Response>

Di seguito si riporta un esempio completo di <saml:Response>:

  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
<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  Destination="https://service_provide_assertion_consumer"
  ID="..."
  InResponseTo="..."
  IssueInstant="2020-10-29T11:36:02.708Z" Version="2.0">
    <saml:Issuer>
        https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/POST/SSO
    </saml:Issuer>
    <ds:Signature>
        <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="...">
                <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="..."
      IssueInstant="2020-11-03T09:19:36.785Z"
      Version="2.0">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/POST/SSO
        </saml:Issuer>
        <ds:Signature>
            <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="...">
                    <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>
        <saml:Subject>
            <saml:NameID
              Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
              NameQualifier="https://idserver.servizicie.interno.gov.it/idp/profile/SAML2/POST/SSO">
                RIFERIMENTO ID ENTE
            </saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData
                  InResponseTo="..."
                  NotOnOrAfter="2020-11-03T09:24:36.807Z"
                  Recipient="https://service_provider_assertion_consumer" />
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions
          NotBefore="2020-11-03T09:19:36.785Z"
          NotOnOrAfter="2020-11-03T09:24:36.785Z">
            <saml:AudienceRestriction>
                <saml:Audience>https://sevice_provider</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement
          AuthnInstant="2020-11-03T09:19:33.100Z"
          SessionIndex="....">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>https://www.spid.gov.it/SpidL3</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
        <saml:AttributeStatement>
            <saml:Attribute FriendlyName="Data di Nascita" Name="dateOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">AAAA-MM-GG</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute FriendlyName="Codice Fiscale" Name="fiscalNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">TINIT-CODICE_FISCALE</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute FriendlyName="Nome" Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">NOME</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute FriendlyName="Cognome" Name="familyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xsi:type="xs:string">COGNOME</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>

3.3. Logout

Lo schema di autenticazione Entra con CIE, nella versione attuale, non implementa il Single logout SAML. Il meccanismo di logout previsto gestisce la sola sessione relativa all’Identity Provider non propagando il logout sulle relative sessioni dei Service Provider. A tal proposito é onere del Service Provider garantire il logout al proprio servizio autenticato tramite un apposito endpoint presente nei metadata dell’Identity Provider all’interno del tag <SingleLogoutService> che viene invocato mediante HTTP-GET e che reinderizza su una apposita pagina dell’IdP server CieID recante il messaggio «Logout effettuato con successo».

Schermata di logout

Fig. 3.2 Schermata di conferma di avvenuto Logout.