SPID - Regole Tecniche¶
SPID, il Sistema Pubblico di Identità Digitale, è la soluzione che permette di accedere a tutti i servizi online della Pubblica Amministrazione con un’unica Identità Digitale (username e password) utilizzabile da computer, tablet e smartphone. Maggiori informazioni sono riportate nel sito www.spid.gov.it
Le Regole Tecniche definiscono le specifiche per l’integrazione di Identity Provider, Service Provider ed Attribute Authority mediante il protocollo SAML.
Nota
Questo documento è la versione consolidata delle Regole Tecniche emanate dall’Agenzia per l’Italia Digitale, con applicati gli Avvisi che le emendano, per una facile consultazione da parte degli sviluppatori. I contenuti sono aderenti ai documenti ufficiali, disponibili nel sito AgID, ma sono presentati secondo una differente struttura dei capitoli e sono arricchiti da informazioni utili indicate con le diciture «Nota» e «Questo paragrafo ha scopo informativo e non normativo».
Questo Documento comprende le specifiche contenuto nell Avviso AgID n° 34 e precedenti.
Indice dei contenuti¶
Introduzione¶
SPID è basato sul framework SAML (Security Assertion Markup Language), sviluppato e manutenuto dal Security Services Technical Committee di OASIS, che permette la realizzazione di un sistema sicuro di Single Sign-On (SSO) federato. Grazie a SAML, un utente può accedere ad una moltitudine di servizi appartenenti a domini differenti effettuando un solo accesso.
Il sistema è composto da 3 entità :
- Gestore delle identità (Identity Provider o IdP) che gestisce gli utenti e la procedura di autenticazione;
- Fornitore di servizi (Service Provider o SP) che, dopo aver richiesto l’autenticazione dell’utente all’Identity Provider, ne gestisce l’autorizzazione sulla base degli attributi restituiti dal Gestore dell’identità , ed eroga il servizio richiesto;
- Gestore di attributi qualificati (Attribute Authority o AA) che fornisce attributi qualificati (ad esempio titoli di studio, iscrizione ad albi, ecc.) sulla base dell’utente autenticato.
Le modalità di funzionamento di SPID sono quelle previste da SAML v2 per il profilo «Web Browser SSO» - SAML V2.0 Technical Overview - Oasis par4.3.
Metadata¶
Ciascuna entità presente nella federazione SPID è descritta da un file di metadati, che ne riporta il certificato X509, gli endpoint e le altre informazioni necessarie alla comunicazione con le altre entità .
Nota
La distribuzione dei metadati a tutti i soggetti è operata dall’Agenzia per l’Italia Digitale attraverso il Registro.
Avvertimento
I fornitori di servizi pubblici - come identificati nell’Avviso AgID numero 28/2020 - possono continuare ad utilizzare certificati self-signed. Per la richiesta di emissione dei certificati digitali ai fini del Sistema Pubblico delle Identità Digitali (SPID) si rimanda ai seguenti Avvisi: - Avviso AgID n23 - Avviso AgID n23 - modulo di richiesta
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.
Nota
Nonostante sia richiesta la pubblicazione dei metadata nel dominio del Service Provider, la distribuzione dei metadati agli Identity Provider è operata centralmente dall’Agenzia per l’Italia Digitale. Gli Identity Provider di conseguenza non ottengono i metadati direttamente dai Service Provider.
Certificati¶
Nota
spid-compliant-certificates è un tool che automatizza la creazione dei certificati per Privati ed Enti Pubblici.
I certificati di sigillo elettronico utilizzati dai SP pubblici e privati sono conformi a RFC-5280 e devono contenere le seguenti estensioni, valorizzate con il corretto uso di minuscole, maiuscole, lettere accentate e altri segni diacritici:
Nel campo SubjectDN:
commonName (oid 2.5.4.3) — La denominazione che valorizza l’estensione organizationName, eventualmente senza esplicitazione degli acronimi, come riportata nel tag XML <OrganizationDisplayName> del metadata del SP (esempio: “AgIDâ€).
organizationName (oid 2.5.4.10) — Denominazione completa e per esteso del SP, così indicata nei pubblici registri e come riportata nel tag xml <OrganizationName> del metadata del SP (esempio: “Comune di Forlì†e non “COMUNE DI FORLIâ€â€);
uri (oid 2.5.4.83) — EntityID del SP, così come riportato nell’attributo entityID del tag XML <EntityDescriptor> del metadata del SP.
- organizationIdentifier (oid 2.5.4.97)
Codice identificativo unico del SP all’interno della federazione SPID, conforme alla sintassi prevista dalla norma ETSI en 319-412-1, 5.1.4:
SP pubblici valorizzato con il prefisso ‘PA:IT-’ seguito dal codice ipa dell’Ente — esempio, per il Comune di Roma (codice ipa ‘c_h501’) tale estensione è valorizzata come “PA:IT-c_h501â€;
SP privati — la seguente alternativa di codici utilizzando, in ordine di preferenza:
il numero di partita iva, preceduto dal prefisso ‘VAT,’ seguito dal codice ISO 3166-1 α-2 del Paese, seguito dal carattere ‘-’ (esempio, “VATIT-12345678901â€);
per i soggetti non provvisti di partita iva, il codice fiscale, preceduto dal prefisso ‘CF:IT-’ (esempio: “CF: IT-XYZABCAAMGGJ000Wâ€);
Altro codice alternativo fornito da AgID in casi particolari.
countryName (oid 2.5.4.6) — il codice ISO 3166-1 del Paese ove è situata la sede legale del SP (esempio: “ITâ€);
localityName (oid 2.5.4.7) — il nome completo della città ove è situata la sede legale del SP (esempio: Forlì e non Forliâ€).
Nel campo CertificatePolicies:
policyIdentifier — contenente almeno uno dei seguenti identificatori:
Trattandosi di certificati di sigillo elettronico e non di certificati di firma elettronica, gli attributi name (oid 2.5.4.41), surname (oid 2.5.4.4), givenName (oid 2.5.4.42), initials (oid 2.5.4.43) e pseudonym (oid 2.5.4.65) non devono essere utilizzati. Altre estensioni, come ad esempio emailAddress (oid 1.2.840.113549.1.9.1), se presenti, non sono valorizzate con dati personali afferenti a persone fisiche.
Gli SP pubblici possono creare autonomamente i certificati elettronici necessari. I certificati possono anche essere di tipo self-signed. Qualora il SP pubblico utilizzi un certificato dedicato all’apposizione del sigillo elettronico sul proprio metadata e un altro certificato dedicato all’apposizione di sigilli elettronici sulle proprie request, il presente Avviso si applica ad entrambi.
A seguito dell’accreditamento presso AgID, i SP privati ricevono un certificato di federazione emesso dall’infrastruttura a chiave pubblica (pki) che AgID ha istituito appositamente per la gestione dell’intera federazione SPID. Al fine di ottenere detto certificato si deve far riferimento all’Avviso SPID n23/2016 e s.m.i. e compilare il previsto modulo di richiesta. La chiave privata cui tale certificato afferisce è utilizzata dal SP privato per apporre sigilli elettronici avanzati sia sul proprio metadata che sulle proprie request.
Ulteriori estensioni stabilite dagli standard e dalle normative sono liberamente utilizzabili.
Algoritmi crittografici, di hash e tipologia delle chiavi¶
Per la generazione delle chiavi crittografiche i SP utilizzano l’algoritmo rsa (Rivest-Shamir-Adleman) con lunghezza delle chiavi non inferiore a 2048 bit. L’algoritmo impiegato per le impronte crittografiche è il dedicated hash-function 4 definito nella norma ISO/IEC 10118-3, corrispondente alla funzione sha-256. È consentito l’uso della funzione sha-512.
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:
SI DEVE
Nell’elemento
<EntityDescriptor>
deve essere presente il seguente attributo:entityID
indicante l’identificativo (URI) dell’entità univoco in ambito SPID
L’elemento
<IDPSSODescriptor>
contraddistingue l’entità di tipo Identity Provider e deve riportare i seguenti attributi:protocolSupportEnumeration
: che enumera gli URI indicanti i 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
)WantAuthnRequestsSigned
: attributo con valore booleano che impone ai Service Provider che fanno uso di questo Identity provider l’obbligo della firma delle richieste di autenticazione;
all’interno di
<IDPSSODescriptor>
devono essere presenti:l’elemento
<KeyDescriptor>
che contiene l’elenco dei certificati e delle corrispondenti chiavi pubbliche dell’entità , utili per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAMLMetadata, par. 2.4.1.1)l’elemento
<NameIDFormat>
riportante l’attributo:format
, indicante il formatourn:oasis:names:tc:SAML:2.0:nameidformat:transient
come quello supportato per l’elemento di<NameID>
utilizzato nelle richieste e risposte SAML per identificare l’identificativo del soggetto (subject id) cui si riferisce un’asserzione
uno o più elementi
<SingleSignOnService>
che specificano l’indirizzo del Single Sign-On Service riportanti i seguenti attributi:Location
URL endpoint del servizio per la ricezione delle richiesteBinding
che può assumere uno dei valoriurn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
uno o più elementi
<SingleLogoutService>
che specificano l’indirizzo del Single Logout Service riportanti i seguenti attributi:Location
URL endpoint del servizio per la ricezione delle richieste di Single Logout;Binding
che può assumere uno dei valoriurn: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
Nota
Ad oggi, nessun Identity Provider espone un SingleLogoutService basato su SOAP.
ResponseLocation
(opzionale): URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout.
opzionalmente possono essere presenti:
uno o più elementi
<Attribute>
ad indicare nome e formato degli attributi SPID certificabili dell’Identity Provider (cfr. Tabella attributi SPID), riportanti gli attributi:Name
: nome dell’attributo SPID (colonna identificatore della Tabella attributi SPID)xsi:type
: tipo dell’attributo (colonna tipo della Tabella attributi SPID)
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. Gli SP pubblici possono creare autonomamente i certificati elettronici necessari e questi possono essere anche di tipo self-signed. I Fornitori Privati dovranno fare invece richiesta presso AgID.
SI PUÃ’
È consigliata la presenza di un elemento
<Organization>
a indicare l’organizzazione a cui afferisce l’entità specificata, riportante gli elementi:<OrganizationName>
indicante un identificatore language-qualified dell’organizzazione a cui l’entità afferisce<OrganizationURL>
riportante in modalità language-qualified la URL istituzionale dell’organizzazione.
Esempio: metadata IdP¶
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’entitaÌ€ (poicheÌ si tratta di un’entitaÌ€ SAML 2.0, deve indicare almeno il valore del relativo protocollo:urn:oasis:names:tc:SAML:2.0:protocol
);AuthnRequestSigned
: valorizzatotrue
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 valoreurn: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 valore0
; - l’attributo
isDefault
posto al valoretrue
;
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 valoriurn: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):
- IPACode — Presente solo per il SP pubblico, è valorizzato con il codice ipa dell’Ente.
- VATNumber — Obbligatorio per il SP privato dotato di partita iva (altrimenti facoltativo), è valorizzato comprensivo del codice ISO 3166-1 α-2 del Paese (senza spazi).
- FiscalCode — Obbligatorio per il SP privato non dotato di partita iva (altrimenti facoltativo), è valorizzato con il codice fiscale del SP.
- 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).
Informazioni obbligatorie per la fatturazione¶
L’occorrenza di ContactPerson con l’attributo contactType valorizzato come billing è obbligatoria in caso sia presente l’estensione Private nel tag Extensions (dell’occorrenza di ContactPerson con l’attributo contactType valorizzato come other). Contiene le informazioni fiscali minime per l’individuazione del soggetto che sarà il destinatario di fatturazione elettronica, in qualità di committente, da parte degli IdP. Al suo interno sono presenti i seguenti tag:
- Extensions (1 occorrenza obbligatorio) — Tramite estensione con opportuno namespace https://spid.gov.it/invoicing-extensions, ispirato dallo standard FatturaPA dell’Agenzia delle Entrate, contiene i tag minimi necessari alla suddetta individuazione fiscale. Sono dunque presenti il tag figlio CessionarioCommittente e, qualora necessario, il tag figlio TerzoIntermediarioSoggettoEmittente, valorizzati come previsto dallo standard:
- CessionarioCommittente (1 occorrenza) — con figli:
- DatiAnagrafici (1 occorrenza) — con figli: IdFiscaleIVA (figli:
- IdPaese e IdCodice) e/o CodiceFiscale; Anagrafica (figli: Denominazione, ovvero Nome e Cognome; opzionalmente Titolo; opzionalmente CodiceEORI);
- Sede (1 occorrenza) — con figli: Indirizzo, NumeroCivico (opzionale), CAP, Comune, Provincia (opzionale), Nazione.
- TerzoIntermediarioSoggettoEmittente (0 o 1 occorrenze) — valorizzato, se necessario e solo relativamente al committente.
- Company (0 o 1 occorrenze) — Obbligatoriamente presente qualora il soggetto per l’emissione delle fatture sia distinto dal SP stesso (e in ogni caso riportante il nome completo e per esteso di una persona giuridica, con il corretto uso di minuscole, maiuscole e segni diacritici).
- EmailAddress (1 occorrenza, obbligatorio) — Contiene l’indirizzo di posta elettronica, aziendale o istituzionale, per contattare il soggetto per questioni di fatturazione elettronica. Può trattarsi di un indirizzo di posta elettronica certificata (pec) aziendale, ma non deve trattarsi di una casella e-mail personale.
Esempio: Contatti metadata SP per Fatturazione¶
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>
|
Esempio: metadata SP¶
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>
|
Trasmissione dei messaggi (binding)¶
La trasmissione dei messaggi tra le entità della federazione SPID può avvenire secondo le due modalità previste da SAML:
- HTTP-Redirect
- HTTP-POST
Binding HTTP-Redirect¶
Nel caso del binding HTTP-Redirect la richiesta viene veicolata con le seguenti modalità :
- 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»).
- Il Location Header del messaggio HTTP contiene l’URI di destinazione del servizio esposto dall’entità destinataria.
- 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»):
- 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
oppureSAMLResponse
. 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>
eLogoutRequest
, mentre deve essere denominatoSAMLResponse
nel trasporto dei messaggi<Response>
e<LogoutResponse>
.
- Il parametro deve essere denominato
- 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 - La form HTML è corredata da uno script che la rende auto-postante all’indirizzo indicato nell’attributo
action
corrispondente alla Location del SingleSignOnService. - 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.
Single Sign-On¶
Il meccanismo di autenticazione è innescato dalla selezione, da parte dell’utente, del Gestore delle Identità con cui intende effettuare l’accesso; tale selezione avviene all’interno del sito del Fornitore di Servizi mediante un bottone ufficiale «Entra con SPID» da integrarsi nel servizio. Il Fornitore di Servizi prepara di conseguenza una <AuthnRequest>
da inoltrarsi al Gestore delle Identità , dove l’utente viene reindirizzato per effettuare l’autenticazione. Eseguita l’autenticazione, l’utente torna presso il sito del Fornitore di Servizi con un’asserzione firmata dal Gestore delle Identity contenente gli attributi richiesti (ad es. nome, cognome, codice fiscale) che il Fornitore di Servizi può usare per autorizzare l’utente in base alle proprie policy ed erogare il servizio richiesto.
Descrizione | SAML | Binding | |
---|---|---|---|
A | L’utente richiede l’accesso ad un servizio | ||
B1 | Il Service Provider (SP) invia allo User Agent (UA) una richiesta di autenticazione da far pervenire all’Identity Provider (IdP) | AuthnRequest |
HTTP POST/REDIRECT |
B2 | Lo User Agent inoltra la richiesta di autenticazione contattando L’Identity Provider | AuthnRequest |
HTTP POST/REDIRECT |
C1 | L’Identity Provider esamina la richiesta ricevuta e, se necessario, esegue una challenge di autenticazione con l’utente | ||
C2 | L’Identity Provider, portata a buon fine l’autenticazione, effettua lo user login e prepara l’asserzione contenente lo statement di autenticazione dell’utente destinato al Service Provider (più eventuali statement di attributo emessi dall’Identity Provider stesso) | ||
D | L’Identity Provider restituisce allo User Agent la <Response> SAML contenente l’asserzione preparata al punto precedente |
Response |
HTTP POST |
E | Lo User Agent inoltra al Service Provider (SP) la <Response> SAML emessa dall’Identity Provider |
Response |
HTTP POST |
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.
SI DEVE
nell’elemento
<AuthnRequest>
devono essere presenti i seguenti attributi:l’attributo
ID
univoco, per esempio 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à )l’attributo
Version
, che deve valere sempre2.0
, coerentemente con la versione della specifica SAML adottata;l’attributo
IssueInstant
a indicare l’istante di emissione della richiesta, in formato UTC (esempio:2017-03-05T18:03:10.531Z
)l’attributo
Destination
, valore dell’attributo Location esposto dal SingleSignOnService dell’IdP al quale è inviata la richiesta.Avvertimento
Il valore richiesto per l’attributo Destination in SPID può corrispondere all’entityID dell’Identity Provider a cui è inviata la richiesta. Tuttavia lâ€Avviso 11 SPID consente ai Service Provider di implementare questo parametro come da standard Saml2.
l’attributo
ForceAuthn
nel caso in cui si richieda livelli di autenticazione superiori a SpidL1 (SpidL2 o SpidL3)l’attributo
AssertionConsumerServiceIndex
, riportante un indice posizionale facente riferimento ad uno degli elementi<AssertionConsumerService>
presenti nei metadata del Service Provider, atto ad indicare, mediante l’attributoLocation
, l’URL a cui inviare il messaggio di risposta alla richiesta di autenticazione, e mediante l’attributoBinding
, il binding da utilizzare, quest’ultimo valorizzato obbligatoriamente conurn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
. In alternativa all’attributoAssertionConsumerServiceIndex
(scelta sconsigliata) possono essere presenti:- l’attributo
AssertionConsumerServiceURL
ad indicare l’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); - l’attributo
ProtocolBinding
, identificante il binding da utilizzare per inoltrare il messaggio di risposta, valorizzato conurn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
;
- l’attributo
nell’elemento
<AuthnRequest>
non deve essere presente l’attributoIsPassive
(ad indicarefalse
come valore di default)deve essere presente l’elemento
<Issuer>
attualizzato come l’attributoentityID
riportato nel corrispondente SP metadata, a indicare l’identificatore univoco del Service Provider emittente. L’elemento deve riportare gli attributi:Format
fissato al valoreurn:oasis:names:tc:SAML:2.0:nameid-format:entity
NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI riconducibile al Service Provider stesso)
deve essere presente l’elemento
<NameIDPolicy>
avente l’attributo:Format
valorizzato comeurn:oasis:names:tc:SAML:2.0:nameid-format:transient
deve essere presente l’elemento
<RequestedAuthnContext>
(SAMLCore, sez. 3.3.2.2.1) ad indicare il contesto di autenticazione atteso, ossia la «robustezza» delle credenziali richieste. Allo scopo sono definite le seguenti «authentication context class» estese (SAMLAuthContext, sez. 3) in riferimento SPID:https://www.spid.gov.it/SpidL1
https://www.spid.gov.it/SpidL2
https://www.spid.gov.it/SpidL3
referenziate dagli elementi
<AuthnContextClassRef>
Ciascuna di queste classi indica in ordine di preferenza il contesto di autenticazione (atteso o effettivo) secondo alcune dimensioni di riferimento, quali per esempio i meccanismi di autenticazione con cui l’Identity Provider può identificare l’utente. L’elemento
<RequestedAuthnContext>
prevede un attributoComparison
con il quale indicare il metodo per stabilire il rispetto del vincolo sul contesto di abilitazione: i valori ammessi per questo attributo sono:exact
minimum
better
maximum
Nel caso dell’elemento
<RequestedAuthnContext>
, questa informazione si riflette sulle tipologie di meccanismi utilizzabili dall’Identity Provider ai fini dell’autenticazione dell’utente. L’esempio seguente di<RequestedAuthnContext>
fa riferimento a una «authentication context class» di tipo SpidL2 o superiore.1 2 3 4 5
<samlp:RequestedAuthnContext Comparison="minimum"> <saml:AuthnContextClassRef> https://www.spid.gov.it/SpidL2 </saml:AuthnContextClassRef> </samlp:RequestedAuthnContext>
N.B. L’Identity Provider ha facoltà di utilizzare per l’autenticazione un livello SPID più alto rispetto a quelli risultanti dall’indicazione del richiedente mediante l’attributo Comparison. Tale scelta non deve comportare un esito negativo della richiesta.
nel caso del binding HTTP POST deve essere presente l’elemento
<Signature>
contenente la firma sulla richiesta apposta dal Service Provider. La firma deve essere 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.
SI PUÃ’
può essere presente l’elemento
<Subject>
a indicare il soggetto per cui si chiede l’autenticazione in cui deve comparire:l’elemento
<NameID>
atto a qualificare il soggetto in cui sono presenti i seguenti attributi:Format
che deve assumere il valoreurn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
(cfr. SAMLCore, sez. 8.3)NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI)
Avvertimento
L’obbligatorietà dell’attributo
NameQualifier
differisce da quanto previsto dalle specifiche SAML.
l’elemento
<Conditions>
, se presente, deve indicare i limiti di validità attesi dell’asserzione ricevuta in risposta, per esempio specificando gli attributiNotBefore
eNotOnOrAfter
opportunamente valorizzati in formato UTC.N.B. L’Identity Provider non è obbligato a tener conto dell’indicazione nel caso che questa non sia confacente con i criteri di sicurezza da esso adottati.
se presente l’elemento
<Scoping>
il relativo attributoProxyCount
deve assumere valore0
per indicare che l’Identity Provider invocato non può delegare il processo di autenticazione ad altra Asserting Party.eventuali elementi
<RequesterID>
contenuti devono indicare l’URL del servizio di reperimento metadati di ciascuna delle entità che hanno emesso originariamente la richiesta di autenticazione e di quelle che in seguito la hanno propagata, mantenendo l’ordine che indichi la sequenza di propagazione (il primo elemento<RequesterID>
dell’elemento<Scoping>
è relativo all’ultima entità che ha propagato la richiesta).Gli elementi
<Scoping>
<RequesterID>
sono previsti per futuri usi ed al momento non devono essere utilizzati. Nel caso di presenza di tali parametri nella richiesta questi dovranno essere al momento ignorati all’atto dell’elaborazione della risposta da parte dell’Identity Provider.
Autenticazione con identità digitale uso professionale o per la persona giuridica¶
Per i casi in cui il fornitore di servizi richieda una Autenticazione per i seguenti profili:
- Identità digitale della persona giuridica
- Identità digitale ad uso professionale della persona fisica
- Identità digitale ad uso professionale per la persona giuridica
si applicano le seguenti specifiche tecniche:
Esempio di AuthnRequest¶
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:
SI DEVE
Nell’elemento
<Response>
devono essere presenti i seguenti attributi:- l’attributo
ID
univoco basato, per esempio, su un Universally Unique Identifier (UUID) (cfr. UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità ); - deve essere presente l’attributo
Version
, che deve valere sempre2.0
, coerentemente con la versione della specifica SAML adottata; - deve essere presente l’attributo
IssueInstant
a indicare l’istante di emissione della risposta, in formato UTC; - deve essere presente l’attributo
InResponseTo
, il cui valore deve fare riferimento all’ID della richiesta a cui si risponde; - deve essere presente l’attributo
Destination
, a indicare l’indirizzo (URI
reference) del Service Provider a cui è inviata la risposta;
- l’attributo
Deve essere presente l’elemento
<Status>
a indicare l’esito della AuthnRequest secondo quanto definito nelle specifiche SAML (SAML-Core, par. 3.2.2.1 e successivi) comprendente il sotto-elemento<StatusCode>
ed opzionalmente i sotto-elementi
<StatusMessage>
<StatusDetail>
(Messaggi di errore SPID)
Deve essere presente l’elemento
<Issuer>
a indicare l’entityID dell’entità emittente, cioè l’Identity Provider stesso. L’attributoFormat
deve essere omesso o fissato al valoreurn:oasis:names:tc:SAML:2.0:nameid-format:entity
.Deve essere presente un elemento
<Assertion>
ad attestare l’avvenuta autenticazione, contenente almeno un elemento<AuthnStatement>
; nel caso l’Identity Provider abbia riscontrato un errore nella gestione della richiesta di autenticazione l’elemento<Assertion>
non deve essere presente.
SI PUÃ’
- Può essere presente l’elemento
<Signature>
contenente la firma sulla risposta apposta dall’Identity Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 1024 bit e algoritmo di digest SHA-256 o superiore.
Assertion¶
SI DEVE
Nell’elemento
<Assertion>
devono essere presenti i seguenti attributi:- l’attributo
ID
univoco, per esempio 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à ); - l’attributo
Version
, che deve valere sempre2.0
, coerentemente con la versione della specifica SAML adottata; - l’attributo
IssueInstant
a indicare l’istante di emissione della richiesta, in formato UTC (esempio:2017-03-01T15:05:10.531Z
);
- l’attributo
Deve essere presente l’elemento
<Subject>
a referenziare il soggetto che si è autenticato in cui devono comparire gli elementi:<NameID>
atto a qualificare il soggetto dell’asserzione, in cui sono presenti i seguenti attributi:Format
che deve assumere il valoreurn:oasis:names:tc:SAML:2.0:nameidformat:transient
(SAML Core, par8.3)NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI riconducibile all’Identity Provider stesso)<SubjectConfirmation>
contenente l’attributoMethod
riportante il valoreurn:oasis:names:tc:SAML:2.0:cm:bearer
<SubjectConfirmationData>
riportante gli attributi:Recipient
riportante lâ€AssertionConsumerServiceURL
relativa al servizio per cui è stata emessa l’asserzione e l’attributoNotOnOrAfter
che limita la finestra di tempo durante la quale l’asserzione può essere propagata.InResponseTo
, il cui valore deve fare riferimento all’ID della richiesta.
Deve essere presente l’elemento
<Issuer>
a indicare l’entityID dell’Identity Provider emittente (attualizzato come l’attributoentityID
presente nei corrispondenti IdP metadata) con l’attributoFormat
riportante il valoreurn:oasis:names:tc:SAML:2.0:nameidformat:entity
;Deve essere presente l’elemento
<Conditions>
in cui devono essere presenti:- gli attributi
NotBefore
NotOnOrAfter
; - l’elemento
<AudienceRestriction>
riportante a sua volta l’elemento<Audience>
attualizzato con l’entityID del Service Provider per il quale l’asserzione è emessa.
- gli attributi
Deve essere presente l’elemento
<AuthStatement>
a sua volta contenente l’elemento:<AuthnContext>
riportante nel sotto elemento<AuthnContextClassRef>
la classe relativa all’effettivo contesto di autenticazione (es.https://www.spid.gov.it/SpidL2
);
Nel caso di asserzioni emesse a seguito di richieste di autenticazione per il livello SPID 1 l’elemento
<AuthStatement>
deve avere l’attributoSessionIndex
specificante l’indice della sessione di autenticazione instaurata per l’utente presso il gestore dell’identità; tale elemento non dovrà essere presente nel caso di asserzioni emesse a seguito di richieste di autenticazione per i livelli SPID 2 e SPID 3.Deve essere presente l’elemento
<Signature>
riportante la firma che l’entità emittente (SP) appone sull’envelope XML da inoltrare. La firma deve essere prodotta secondo il profilo specificato per SAML (cfr [SAML-Core] cap5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.
SI PUÃ’
Può essere presente l’elemento
<AttributeStatement>
riportante gli attributi identificativi certificati dall’Identity Provider. Tale elemento se presente dovrà comprendere:- uno o più elementi di tipo
<Attribute>
relativi ad attributi che l’Identity Provider può rilasciare (cfr. Tabella attributi SPID) su richiesta del Service Provider espressa attraverso l’attributoAttributeConsumingServiceIndex
nella AuthnRequest; - per gli elementi
<AttributeValue>
si raccomanda l’uso dell’attributoxsi:type
attualizzato come specificato nella Tabella attributi SPID;
- uno o più elementi di tipo
Può essere presente un elemento
<Advice>
, contenente a sua volta altri elementi<Assertion>
. La possibile presenza dell’elemento, prevista per futuri usi, consente, nei casi in cui gli statement emessi dall’Identity Provider si basino su altre asserzioni SAML ottenute da altre authority, di fornire evidenza delle stesse in forma originale unitamente alla risposta alla richiesta di autenticazione.
L’elemento <Advice>
è previsto per futuri usi ed al momento non deve essere utilizzato.
Esempio di Response con Assertion¶
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>
|
Processamento della Response¶
Alla ricezione della <Response>
qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve operare almeno le seguenti verifiche:
controllo delle firme presenti nella
<Assertion>
e nella<Response>
;nell’elemento
<SubjectConfirmationData>
verificare che:- 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
- l’attributo
Il fornitore di servizi deve 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, secondo l’attributo NotOnOrAfter
dell’elemento <SubjectConfirmationData>
presente nell’asserzione stessa. Più semplicemente un SP deve esclusivamente accettare Response riconducibili a Richieste di Autenticazione già inoltrate e non scadute, Response non sollecitate da precedenti AuthnRequest devono essere pertanto scartate.
Single Logout¶
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:
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;
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;
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 neÌ 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.
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.
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.
Sessioni individuali¶
E’ lasciata ai fornitori di servizi la scelta delle modalità da adottare per la gestione del ciclo di vita delle sessioni individuali. In particolare le sessioni individuali possono:
- non essere affatto instaurate (il fornitore di servizi eroga il servizio richiesto dall’utente senza, per quanto possibile, stabilire con esso alcuna sessione);
- essere chiuse anche nel corso di validità della sessione di autenticazione che le ha originate (ovvero prima di una eventuale richiesta di Single Logout o della scadenza del timeout associato alla sessione di autenticazione).
In entrambi i casi i fornitori di servizio devono essere comunque in condizione di supportare il processo di Single Logout notificando, a fronte della prevista richiesta da parte del gestore delle identità, l’avvenuta chiusura delle sessioni mai instaurate o già in precedenza chiuse. I fornitori di servizio che instaurano sessioni individuali dovranno mettere a disposizioni dell’utente funzionalità per la richiesta della chiusura della sessione individuale o della sessione globale.
Meccanismi di Single Logout¶
Per la realizzazione del processo di Single Logout secondo quanto previsto dal SAML Single Logout Profile le entità coinvolte (gestore dell’identità e fornitori di servizi) dovranno mettere a disposizione una apposita interfaccia per la notifica dei messaggi:
- SingleLogoutService: ricezione di richieste e notifiche per il Single Logout SAML.
Le tabelle seguenti specificano i passi previsti ed il flusso di messaggi che intercorrono tra il gestore delle identità, l’utente ed i fornitori di servizi nel corso del processo di Single Logout, nei due casi distinti in cui l’inizio avviene presso il gestore dell’identità oppure presso uno dei fornitori di servizi.
Descrizione | SAML | Binding | |
---|---|---|---|
1 | L’utente utilizzando il browser (User Agent) richiede il Single Logout presso un fornitore di servizi | ||
2 | Il fornitore di servizi procede con la chiusura della propria sessione individuale ed invia una richiesta | LogoutRequest | HTTP-Redirect, HTTP-POST |
3 | Il gestore dell’identità ricevuta la richiesta chiude la sessione di autenticazione associata alla sessione globale. Successivamente per ciascun fornitore di servizi facente parte della sessione globale, a partire da quelli in grado di supportare il bindind SOAP, procede alla chiusura delle sessioni individuali. In particolare: | ||
3.1 | invia una richiesta di logout all’i- esimo fornitore di servizi riportando l’identificatore associato alla sessione globale che si vuole chiudere | LogoutRequest | SOAP, HTTP-Redirect, HTTP-POST |
3.2 | l’i-esimo fornitore di serviziricevuta la richiesta chiude la sessione identificata ( se la stessa non fosse stata già chiusa in precedenza o mai instaurata) ed invia una notifica di avvenuta chiusura al gestore dell’identità | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST |
3.3 | Se l’i-esimo fornitore di servizi non è raggiungibile il processo degrada a partial logout | ||
4 | Il gestore dell’identità completata la notifica a ciascun fornitore di servizi facente parte della sessione globale trasmette l’esito (success/partial logout) del global logout al fornitore di servizi che aveva dato inizio al processo. | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST |
Descrizione | SAML | Binding | |
---|---|---|---|
1 | L’utente utilizzando il browser (User Agent) richiede il Single Logout presso il gestore dell’identità | ||
2 | Il gestore dell’identità ricevuta la richiesta chiude la sessione di autenticazione associata alla sessione globale. Successivamente per ciascun fornitore di servizi facente parte della sessione globale, a partire da quelli in grado di supportare il bindind SOAP, procede alla chiusura delle sessioni individuali. In particolare: | ||
2.1 | invia una richiesta di logout all’i-esimo fornitore di servizi riportando l’identificatore associato alla sessione globale che si vuole chiudere | LogoutRequest | SOAP, HTTP-Redirect |
2.2 | L’iesimo fornitore di servizi ricevuta la richiesta chiude la sessione identificata ( se la stessa non fosse stata già chiusa in precedenza o mai instaurata) ed invia una notifica di avvenuta chiusura al gestore dell’identità | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST |
2.3 | Se l’i-esimo fornitore di servizi non è raggiungibile il processo degrada a partial logout |
Il risultato della sequenza di scambio è la chiusura della sessione globale.
In condizioni di anomalia derivate da una mancata, intempestiva o non corretta risposta da parte di uno o più fornitori di servizi coinvolti nella sessione, il processo di Single Logout degrada ad un partial logout. In questo caso alla fine del processo risulteranno chiuse la sessione di autenticazione e la sessione individuale presso il fornitore dei servizi presso cui viene operata la richiesta di Single Logout ma non si potrà avere garanzia sulla effettiva chiusura delle altre sessioni individuali facenti parte della sessione globale. Nel caso di richiesta di Single Logout operata presso un fornitore di servizi (Tabella 1) il gestore dell’identità nel caso di operazione conclusa con successo dovrà notificare tale situazione al fornitore di servizi richiedente, riportando nella response il seguente status code:
- StatusCode:
urn:oasis:names:tc:SAML:2.0:status:Success
Viceversa nel caso in cui si verificasse una condizione di partial logout il gestore dell’identità, se in condizione di poterlo fare, dovrà notificare tale esito al fornitore di servizi richiedente, riportando nella response i seguenti status code:
- StatusCode:
urn:oasis:names:tc:SAML:2.0:status:Requester
- sub-StatusCode:
urn:oasis:names:tc:SAML:2.0:status:PartialLogout
Quest’ultimo comportamento deve essere assunto dal gestore dell’identità anche nel caso di una richiesta di Single Logout operata presso un fornitore di servizi e presentata dopo la scadenza della sessione globale, a seguito del timeout della relativa sessione di autenticazione o della esplicita chiusura della stessa da parte dell’utente.
LogoutRequest¶
Nota
Come sopra descritto, il messaggio di LogoutRequest può essere inviato dal Service Provider all’Identity Provider o viceversa, a seconda dell’entità presso la quale l’utente ha richiesto il Single Logout.
Il messaggio di LogoutRequest deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:
SI DEVE
Nell’elemento
<LogoutRequest>
devono essere presenti i seguenti attributi:- l’attributo
ID
univoco, per esempio 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à); - l’attributo
Version
, che deve valere sempre2.0
, coerentemente con la versione della specifica SAML adottata; - l’attributo
IssueInstant
a indicare l’istante di emissione della richiesta, in formato UTC (esempio:2008-03-13T18:04:15.531Z
); - l’attributo
Destination
, a indicare l’indirizzo (URI reference) dell’entità (gestore delle identità o fornitori di servizi) a cui è inviata la richiesta.
- l’attributo
Nell’elemento
<LogoutRequest>
devono essere presenti i seguenti elementi:l’elemento
<Issuer>
attualizzato come l’attributoentityID
riportato nel corrispondente metadata, a indicare l’identificatore univoco dell’entità (gestore delle identità o fornitori di servizi) emittente. L’elemento deve riportare gli attributi:Format
fissato al valoreurn:oasis:names:tc:SAML:2.0:nameid-format:entity
;NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI riconducibile alla stessa entità emittente);
l’elemento
<NameID>
atto a qualificare il soggetto a cui si riferisce l’evento di autenticazione che ha dato origine alla sessione, in cui sono presenti i seguenti attributi:Format
che deve assumere il valoreurn:oasis:names:tc:SAML:2.0:nameid- format:transient
(cfr. SAMLCore, sez. 8.3);NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI riconducibile al gestore dell’identità che ha emesso l’asserzione);
l’elemento
<SessionIndex>
atto ad identificare la sessione a cui la richiesta di chiusura si riferisce;
Deve essere presente l’elemento
<Signature>
contenente la firma sulla richiesta apposta dal Service Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (cfr [SAML-Core] cap5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.
LogoutResponse¶
Nota
Come sopra descritto, il messaggio di LogoutResponse può essere inviato dal Service Provider all’Identity Provider o viceversa, a seconda dell’entità presso la quale l’utente ha richiesto il Single Logout.
Il messaggio di LogoutResponse deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:
SI DEVE
Nell’elemento
<LogoutResponse>
devono essere presenti i seguenti elementi:- l’attributo
ID
univoco, per esempio basato su un Universally Unique Identifier (UUID) (cfr. UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità); - deve essere presente l’attributo
Version
, che deve valere sempre2.0
, coerentemente con la versione della specifica SAML adottata; - deve essere presente l’attributo
IssueInstant
a indicare l’istante di emissione della risposta, in formato UTC; - deve essere presente l’attributo
InResponseTo
, il cui valore deve fare riferimento all’ID della richiesta a cui si risponde; - deve essere presente l’attributo
Destination
, a indicare l’indirizzo (URI reference) dell’entità (gestore delle identità o fornitori di servizi) a cui è inviata la risposta;
- l’attributo
Nell’elemento
<LogoutResponse>
devono essere presenti i seguenti elementi:deve essere presente l’elemento
<Issuer>
a indicare l’entityID
dell’entità emittente; l’elemento deve riportare gli attributi:Format
fissato al valoreurn:oasis:names:tc:SAML:2.0:nameid-format:entity
;NameQualifier
che qualifica il dominio a cui afferisce tale valore (URI riconducibile alla stessa entità emittente);
deve essere presente l’elemento
<Status>
a indicare l’esito della LogoutRequest secondo quanto definito nelle specifiche SAML (cfr. [SAML-Core] par. 3.2.2.1 e ss.) comprendente il sotto-elemento<StatusCode>
ed opzionalmente i sotto-elementi<StatusMessage>
e<StatusDetail>
(cfr [SPID-TabErr]);
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.
Impiego del binding SOAP¶
Nel caso in cui i fornitori di servizi dispongano del binding SOAP i gestori dell’identità potranno utilizzarlo, preferendolo questo agli altri Binding. La richiesta di Single Logout, quando operata dall’utente presso un fornitore di servizi, sarà iniziata utilizzando uno dei binding asincroni resi disponibili dai gestori dell’identità, per dar modo ai gestori dell’identità di completare il processo anche presso i fornitori di servizi sprovvisti di interfacce SOAP.
Gestori di attributi qualificati (Attribute Authority)¶
Avvertimento
Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.
Nota
È in corso, presso l’Agenzia per l’Italia Digitale, un Gruppo di Lavoro per la ridefinizione delle regole tecniche per i gestori di attributi qualificati. È possibile che le regole ad oggi vigenti subiscano modifiche.
Soggetti Aggregatori¶
I Soggetti Aggregatori sono pubbliche amministrazioni o privati che offrono a terzi (soggetti aggregati) la possibilità di rendere accessibili tramite lo SPID i rispettivi servizi. Tali soggetti si distinguono in aggregatori di servizi pubblici e aggregatori di servizi privati.
Per le specifiche per Soggetti Aggregatori si rimanda ai seguenti avvisi:
Registro¶
Il Registro SPID è il repository di tutte le informazioni relative alla entità aderenti a SPID e costituisce l’evidenza del cosiddetto circle of trust in esso stabilito. La relazione di fiducia su cui si basa la federazione stabilita in SPID si realizza per il tramite dell’intermediazione dell’Agenzia, terza parte garante, attraverso il processo di accreditamento dei gestori dell’identità digitale, dei gestori degli attributi qualificati e dei fornitori di servizi. L’adesione a SPID costituisce l’instaurazione di una relazione di fiducia con tutti i soggetti già aderenti, accreditati dall’Agenzia, sulla base della condivisione dei livelli standard di sicurezza dichiarati e garantiti da SPID. L’adesione al patto di fiducia tra le entità aderenti (gestori dell’identità digitale, gestori degli attributi qualificati e fornitori di servizi) si evidenzia nella presenza di tali entità nel Registro SPID gestito dall’Agenzia.
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.
Nota
Non è al momento attivo un Discovery Service.
Accesso al Registro¶
Avvertimento
Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.
Nota
Il Registro è disponibile alla URL https://registry.spid.gov.it/
Accesso al Registro in modalità LDAP¶
Avvertimento
Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.
Nota
L’accesso via LDAP non è al momento attivo.
Log¶
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_
IssuerResp_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
Tabella attributi¶
L’identificatore sotto indicato è il valore dell’attributo Name
dell’elemento <saml:Attribute>
. Il valore dell’attributo NameFormat
dello stesso elemento è, come da specifica SAML-core, urn:oasis:names:tc:SAML:2.0:attrname-format:basic
.
Il tipo sotto indicato è il valore dell’attributo xsi:type
dell’elemento <saml:AttributeValue>
.
Attributo | Identificatore | Tipo | Note |
---|---|---|---|
Codice identificativo | spidCode |
xs:string | Il codice identificativo è assegnato dal gestore dell’identità digitale, deve essere univoco in ambito SPID. Il formato è il seguente:
dove:
(Es. |
Nome | name |
xs:string | Stringa composta da una sequenza di una o più sottostringhe non vuote con carattere iniziale in maiuscolo intervallate da uno (solo) spazio (Es. |
Cognome | familyName |
xs:string | Stringa composta da una sequenza di una o più sottostringhe non vuote con carattere iniziale in maiuscolo intervallate da uno (solo) spazio (Es. |
Luogo di nascita | placeOfBirth |
xs:string | Stringa corrispondente al codice catastale (Codice Belfiore) del Comune o della nazione estera di nascita. (Es. |
Provincia di nascita | countyOfBirth |
xs:string | Stringa corrispondente alla sigla della provincia di nascita. (Es. |
Data di nascita | dateOfBirth |
xs:date | Secondo specifica xs:date nel formato YYYY-MM-DD dove:
(Es. |
Sesso | gender |
xs:string | Valori ammessi:
|
Ragione o denominazione sociale | companyName |
xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio. In maiuscolo le sottostringhe corrispondenti a nomi. (Es. |
Sede legale | registeredOffice |
xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio rappresentanti:
(Es. |
Codice fiscale | fiscalNumber |
xs:string | Per il formato si faccia riferimento alla codifica dell’attributo CF per i certificati, proposta nell’ambito del Draft ETSI EN 319 412-1, che nel caso specifico prevede la seguente composizione:
|
Partita IVA | ivaCode |
xs:string | Per il formato si faccia riferimento alla codifica dell’attributo Partita IVA per i certificati, proposta nell’ambito del Draft ETSI EN 319 412-1, che nel caso specifico prevede la seguente composizione:
|
Documento d’identità | idCard |
xs:string | Stringa composta dalla sequenza di sottostringhe (non vuote) concatenate nell’ordine sotto riportato e intervallate da uno (solo) spazio: * <tipo di documento> xs:string; valori ammessi: cartaIdentita, passaporto, patenteGuida; patenteNautica; librettoPensione, patentinoImpTermici, portoArmi, tesseraRiconoscimento; * <numero di documento> xs:string; Numero del documento; * <ente emettitore> xs:string; stringa ottenuta dalla concatenazione dei termini costituenti la denominazione dell’ente a meno di congiunzioni, articoli e preposizioni.
(Es. |
Attributo | Identificatore | Tipo | Note |
---|---|---|---|
Numero di telefono mobile | mobilePhone |
xs:string | Stringa numerica senza spazi intermedi (Es. |
Indirizzo di posta elettronica | email |
xs:string | Formato standard indirizzo di posta elettronica |
Domicilio | domicileStreetAddress |
xs:string | via, viale, piazza |
Codice Postale | domicilePostalCode |
xs:string | CAP |
Comune | domicileMunicipality |
xs:string | Comune |
Provincia | domicileProvince |
xs:string | |
Domicilio fisico | address |
xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio rappresentanti:
|
Nazione | domicileNation |
xs_string | |
Data di scadenza identità | expirationDate |
xs:date | Secondo specifica xs:date |
Domicilio digitale | digitalAddress |
xs:string | Indirizzo casella PEC |
Avvertimento
L’attributo address è stato sostituito dall Avviso AgID n25
Messaggi di errore¶
Autenticazione corretta¶
Error code: | 1 (Autenticazione corretta) |
---|---|
Binding: | HTTP-POST, HTTP-Redirect |
HTTP status code: | 200 |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Success |
Destinatario notifica: | Fornitore del servizio (SP) |
Anomalie del sistema¶
Error code: | 2 (Indisponibilità sistema) |
---|---|
Binding: | HTTP-POST |
Destinatario notifica: | Utente |
Schermata IdP: | Messaggio di errore generico |
Troubleshooting utente: | Ripetere l’accesso al servizio più tardi |
Error code: | 3 (Errore di sistema) |
---|---|
Binding: | HTTP-Redirect |
HTTP status code: | 500 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Sistema di autenticazione non disponibile - Riprovare più tardi†|
Troubleshooting utente: | Ripetere l’accesso al servizio più tardi |
Note: | Tutti i casi di errore di sistema in cui è possibile mostrare un messaggio informativo all’utente |
Anomalie delle richieste¶
Error code: | 4 (Formato binding non corretto) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
HTTP status code: | 403 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contatare il gestore del servzio†|
Troubleshooting utente: | Contattare il gestore del servizio |
Troubleshooting SP: | Verificare la conformità con le regole tecniche SPID del formato del messaggio di richiesta |
Parametri obbligatori: |
|
Parametri non obbligatori: |
|
Error code: | 5 (Verifica della firma fallita) |
---|---|
Binding: | HTTP-Redirect |
HTTP status code: | 403 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Impossibile stabilire l’autenticità della richiesta di autenticazione - Contattare il gestore del servizio†|
Troubleshooting utente: | Contattare il gestore del servizio |
Troubleshooting SP: | Verificare certificato o modalità di apposizione firma |
Note: | Firma sulla richiesta non presente, corrotta, non conforme in uno dei parametri, con certificato scaduto o con certificato non associato al corretto EntityID nei metadati registrati |
Error code: | 6 (Binding su metodo HTTP errato) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
HTTP status code: | 403 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non ricevibile - Contattare il gestore del servizio†|
Troubleshooting utente: | Contattare il gestore del servizio |
Troubleshooting SP: | Verificare metadata Gestore dell’identita (IdP) |
Note: | Invio richiesta in HTTP-Redirect su entrypoint HTTP-POST dell’identity, oppure invio richiesta in HTTP-POST su entrypoint HTTP-Redirect dell’identity |
Error code: | 7 (Errore sulla verifica della firma della richiesta) |
---|---|
Binding: | HTTP-POST |
HTTP status code: | 403 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contattare il gestore del servizio†|
Troubleshooting utente: | Contattare il gestore del servizio |
Troubleshooting SP: | Verificare certificato o modalità di apposizione firma |
Note: | Firma sulla richiesta non presente, corrotta, non conforme in uno dei parametri, con certificato scaduto o con certificato non associato al corretto EntityID nei metadati registrati |
Error code: | 8 (Formato della richiesta non conforme alle specifiche SAML) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML StatusMessage: | ErrorCode nr08 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare la richiesta secondo le regole tecniche SPID - Fornire pagina di cortesia all’utente |
Note: | Non conforme alle specifiche SAML - Il controllo deve essere operato successivamente alla verifica positiva della firma |
Error code: | 9 (Parametro version non presente, malformato o diverso da 2.0 ) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:VersionMismatch |
SAML StatusMessage: | ErrorCode nr09 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare la richiesta secondo le regole tecniche SPID - Fornire pagina di cortesia all’utente |
Error code: | 10 (Issuer non presente, malformato o non corrispondete all’entità che sottoscrive la richiesta) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
HTTP status code: | 403 |
Destinatario notifica: | Utente |
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contattare il gestore del servizio†|
Troubleshooting utente: | Contattare il gestore del servizio |
Troubleshooting SP: | Verificare formato delle richieste prodotte |
Error code: | 11 (ID non presente, malformato o non conforme) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML StatusMessage: | ErrorCode nr11 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Note: | Identificatore necessario per la correlazione con la risposta. L’eventuale presenza dell’anomalia va verificata e segnalata solo a seguito di una positiva verifica della firma. |
Error code: | 12 (RequestAuthnContext non presente, malformato o non previsto da SPID) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:NoAuthnContext |
SAML StatusMessage: | ErrorCode nr12 |
Destinatario notifica: | Fornitore del servizio (SP) |
Schermata IdP: | Pagina temporanea con messaggio di errore: “Autenticazione SPID non conforme o non specificata†|
Troubleshooting SP: | Informare l’utente |
Note: | Identificatore necessario per la correlazione con la risposta. L’eventuale presenza dell’anomalia va verificata e segnalata solo a seguito di una positiva verifica della firma. |
Error code: | 13 (IssueInstant non presente, malformato o non coerente con l’orario di arrivo della richiesta) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:RequestDenied |
SAML StatusMessage: | ErrorCode nr13 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Error code: | 14 (Destination non presente, malformata o non coincidente con il Gestore delle identità ricevente la richiesta) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported |
SAML StatusMessage: | ErrorCode nr14 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Error code: | 15 (Attributo IsPassive presente e attualizzato al valore true) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:NoPassive |
SAML StatusMessage: | ErrorCode nr15 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Error code: | 16 (AssertionConsumerService non correttamente valorizzato) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported |
SAML StatusMessage: | ErrorCode nr16 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Note: |
|
Error code: | 17 (Attributo Format dell’elemento NameIDPolicy assente o non valorizzato secondo specifica) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported |
SAML StatusMessage: | ErrorCode nr17 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente |
Note: | Nel caso di valori diversi dalla specifica del parametro opzionale AllowCreate si procede con l’autenticazione senza riportare errori |
Error code: | 18 (AttributeConsumerServiceIndex malformato o che riferisce a un valore non registrato nei metadati di SP) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Requester |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported |
SAML StatusMessage: | ErrorCode nr18 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Riformulare la richiesta con un valore dell’indice presente nei metadati |
Anomalie derivanti dall’utente¶
Error code: | 19 (Autenticazione fallita per ripetuta sottomissione di credenziali errate - superato numero tentativi secondo le policy adottate) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr19 |
Destinatario notifica: | HTTP POST/HTTP Redirect |
Schermata IdP: | Messaggio di errore specifico ad ogni interazione prevista |
Troubleshooting utente: | Inserire credenziali corrette |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Note: | Si danno indicazioni specifiche e puntuali all’utente per risolvere l’anomalia, rimanendo nelle pagine dello IdP. Solo al verificarsi di determinate condizioni legate alle policy di sicurezza aziendali, ad esempio dopo 3 tentativi falliti, si risponde al SP. |
Error code: | 20 (Utente privo di credenziali compatibili con il livello HTTP richiesto dal fornitore del servizio) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr20 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting utente: | Acquisire credenziali di livello idoneo all’accesso al servizio richiesto |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Error code: | 21 (Timeout durante l’autenticazione utente) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr21 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting utente: | Si ricorda che l’operazione di autenticazione deve essere completata entro un determinato periodo di tempo |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Error code: | 22 (Utente nega il consenso all’invio di dati al SP in caso di sessione vigente) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr22 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting utente: | Dare consenso |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Note: | Sia per autenticazione da fare, sia per sessione attiva di classe SpidL1. |
Error code: | 23 (Utente con identità sospesa/revocata o con credenziali bloccate) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr23 |
Destinatario notifica: | Fornitore del servizio (SP) |
Schermata IdP: | Pagina temporanea con messaggio di errore: “Credenziali sospese o revocate†|
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Error code: | 24 (Riservato) |
---|---|
Error code: | 25 (Processo di autenticazione annullato dall’utente) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr25 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto |
Error code: | 30 (tentativo dell’utente di utilizzare una tipologia di identità digitale diversa da quanto richiesto dal SP) |
---|---|
Binding: | HTTP-Redirect, HTTP-POST |
SAML StatusCode: | urn:oasis:names:tc:SAML:2.0:status:Responder |
SAML sub-StatusCode: | urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed |
SAML StatusMessage: | ErrorCode nr30 |
Destinatario notifica: | Fornitore del servizio (SP) |
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto. Per maggiori dettagli consultare Avviso 18 <https://www.agid.gov.it/sites/default/files/repository_files/spid-avviso-n18_v.2-_autenticazione_persona_giuridica_o_uso_professionale_per_la_persona_giuridica.pdf>_ |