2. 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 scambio viene avviato nel momento in cui l’utente esprime la volontà di accedere al servizio cliccando il tasto «Entra con CIE» nell’apposita pagina html del Service Provider. In seguito alla pressione del tasto “Entra con CIE” il SP predispone una richiesta di autenticazione (<AuthnRequest>
) e la inoltra, reindirizzando opportunamente l’utente, all’Identity Provider del Ministero dell’Interno.
La componente server dell’Identity Provider (CieID Server) interpreta la richiesta di autenticazione e avvia la cosiddetta fase di “challenge” che varia in funzione del livello di sicurezza richiesto dal Service Provider. In particolare:
- Invita l’utente a verificare le proprie credenziali username e password o a scansionare un QR Code mediante l’app CieID, in caso di accesso con livello di sicurezza “basso” (livello 1);
- Invita l’utente a verificare le proprie credenziali username e password e un secondo fattore di autenticazione OTP o a scansionare un QR Code mediante l’app CieID, in caso di accesso con livello di sicurezza “significativo” (livello 2);
- Invita l’utente a avvicinare la propria CIE sul lettore (RF o NFC) avviando automaticamente il processo di autenticazione mediante la CIE, in caso di accesso con livello di sicurezza “alto” (livello 3). Poggiata la carta sul lettore, allL’utente deve, quindi,viene richiesto di inserire la seconda metà del PIN e confermare.

Fig. 2.1 Processo di autenticazione del CieID Server
Terminato il processo di autenticazione il server CieID mostra una pagina contenente gli attributi qualificati che si stanno per inviare al Service Provider (nome, cognome, data di nascita, codice fiscale e, se richiesti, numero di telefono ed e-mail) desunti dal certificato digitale a bordo della carta. L’utente, informato degli attributi che si stanno per inviare al servizio, fornisce il consenso all’invio e prosegue con l’operazione.
L’Identity Provider reindirizza nuovamente l’utente sul sito del Service Provider, con un'asserzione (<Response>
) digitalmente firmata e contenente gli attributi qualificati richiesti.
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.
2.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 attributiLocation
presenti nel tagSingleSignOnService
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 conurn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
.ForceAuthn
è sempre valorizzato contrue
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 la2.0
.
Nota
- In alternativa, è ammesso l'uso dell'attributo
AssertionConsumerServiceIndex
al posto degli attributiAssertionConsumerServiceURL
eProtocolBinding
. - 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'attributoentityID
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 stringaurn:oasis:names:tc:SAML:2.0:nameid-format:entity
.
<NameIDPolicy>
avente l'attributoFormat
valorizzato con la stringaurn:oasis:names:tc:SAML:2.0:nameid-format:transient
, mentre invece non deve essere presente l'attributoAllowCreate
.<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 comeexact
(default), ovverominimum
;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 sicurezza SPID), secondo lo specifico livello di sicurezza richiesto (dall'utente o dal SP).
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 di livello "alto" (livello 3):
https://www.spid.gov.it/SpidL3
e, equivalentemente,exact
ovverominimum
; - autenticazione di livello almeno "significativo" (livello 2 o superiore):
https://www.spid.gov.it/SpidL2
eminimum
; - autenticazione di livello "basso"" o superiore (livello 1 o superiore):
https://www.spid.gov.it/SpidL1
eminimum
;
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>
.
2.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>
|
2.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'attributolocation
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'attributoentityID
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'attributoValue
, 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.
2.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>
|
2.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 (attributoentityID
) 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'attributoMethod
valorizzato con la stringaurn: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 attributiNotBefore
eNotOnOrAfter
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'elementoAuthnContext
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 tipoxs:string
), valorizzato con il nome del soggetto;familyName
(di tipoxs:string
), valorizzato con il cognome del soggetto;dateOfBirth
(di tipoxs:string
) data di nascita nel formatoYYYY-MM-GG
;fiscalNumber
(di tipoxs:string
), valorizzato con il codice fiscale nel formatoTINIT-<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.
2.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.
2.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>
|
2.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".

Fig. 2.2 Schermata di conferma di avvenuto Logout.