From 29a15be5c8266bcccb716e62635a320bbd5c3634 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 5 Feb 2021 00:55:09 +0100 Subject: [PATCH 1/6] Aggiornamento con Avvisi AgID --- code-samples/idp-metadata.xml | 33 +++++ code-samples/response.xml | 248 +++++++++++++++++++++++++--------- code-samples/sp-metadata.xml | 11 ++ index.rst | 25 +++- metadata.rst | 21 ++- single-sign-on.rst | 24 +++- soggetti-aggregatori.rst | 11 ++ 7 files changed, 296 insertions(+), 77 deletions(-) create mode 100644 soggetti-aggregatori.rst diff --git a/code-samples/idp-metadata.xml b/code-samples/idp-metadata.xml index 44d62e2..73ba6da 100644 --- a/code-samples/idp-metadata.xml +++ b/code-samples/idp-metadata.xml @@ -1,6 +1,8 @@ @@ -39,4 +41,35 @@ + + SPID Identity Provider + SPID Identity Provider + https://spid.identityprovider.it + + + + + + + IT + 983745349857 + + + Destinatario Fatturazione + + + + via tante cose + 12 + 87100 + Cosenza + CS + IT + + + + example s.p.a. + info@example.org + +39 84756344785 + diff --git a/code-samples/response.xml b/code-samples/response.xml index 49bdd10..46ec170 100644 --- a/code-samples/response.xml +++ b/code-samples/response.xml @@ -1,67 +1,183 @@ - - - spididp.it - - - ............. - - - - - - - spididp.it - - - ...... - - - - _06e983facd7cd554cfe067e - - - - - - - - - - https://spidSP.serviceProvider.it - - - - - - - https://www.spid.gov.it/SpidL1 - - - - - - - Rossi - - - - - ABCDEFGHILMNOPQ - - - - + + + http://localhost:8080 + + + + + + + + + + + + + ... + + + + + ... + + + + + ... + + + + + + + + + + + + + https://that.spid.idp.example.org/metadata + + + + + + + + + + + + + 6V8qWljmWULO0C0OQit0DaylE+neFN9K8SXR2izWXpw= + + + + + ... + + + + + ... + + + + + + + + _655df4bc-b372-475e-906d-e71e4d7e98de + + + + + + + + + + http://that.spid.example.org/saml2/metadata + + + + + + + + https://www.spid.gov.it/SpidL1 + + + + + + + + + AGID-001 + + + + + SpidValidator + + + + + AgID + + + + + Roma + + + + + RM + + + + + 2000-01-01 + + + + + M + + + + + Agenzia per l'Italia Digitale + + + + + Via Listz 21 00144 Roma + + + + + TINIT-GDASDV00A01H501J + + + + + VATIT-97735020584 + + + + + CartaIdentità AA00000000 ComuneRoma 2018-01-01 2028-01-01 + + + + + 2028-01-01 + + + + + +393331234567 + + + + + spid.tech@agid.gov.it + + + + + Via Listz 21 00144 Roma + + + + + pec@pecagid.gov.it + + + + + diff --git a/code-samples/sp-metadata.xml b/code-samples/sp-metadata.xml index e17123f..f91f937 100644 --- a/code-samples/sp-metadata.xml +++ b/code-samples/sp-metadata.xml @@ -1,4 +1,6 @@ @@ -42,4 +44,13 @@ Nome service provider http://spid.serviceprovider.it + + + IT12345678901 + XYZABCAAMGGJ000W + + + tech-info@example.org + +39 8472345634785 + diff --git a/index.rst b/index.rst index 9dcdb59..38b50e2 100644 --- a/index.rst +++ b/index.rst @@ -1,14 +1,28 @@ 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. +**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. - -.. WARNING:: - Questo documento è la versione consolidata delle Regole Tecniche emanate dall'Agenzia per l'Italia Digitale, con applicati i successivi 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". +Le Regole Tecniche definiscono le specifiche per l'integrazione di +Identity Provider, Service Provider ed Attribute Authority mediante il protocollo SAML. +.. note:: + 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 SPID n34** + e precedenti. + Indice dei contenuti -------------------- @@ -21,6 +35,7 @@ Indice dei contenuti single-sign-on.rst single-logout.rst attribute-authority.rst + soggetti-aggregatori.rst registro.rst log.rst attributi.rst diff --git a/metadata.rst b/metadata.rst index a5be86a..c07d07c 100644 --- a/metadata.rst +++ b/metadata.rst @@ -6,6 +6,12 @@ Ciascuna entità presente nella federazione SPID è descritta da un file di meta .. Note:: La distribuzione dei metadati a tutti i soggetti è operata dall'Agenzia per l'Italia Digitale attraverso il `Registro `_. +.. Warning:: + 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 `_ + Identity Provider ----------------- @@ -60,8 +66,11 @@ Le caratteristiche dell'Identity provider sono definite attraverso metadata conf * ``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 ```` 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 1024 bit e algoritmo di digest SHA-256 o superiore; - + * Deve essere presente l'elemento ```` 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. + + .. admonition:: SI PUÒ * È consigliata la presenza di un elemento ```` a indicare l'organizzazione a cui afferisce l'entità specificata, riportante gli elementi: @@ -80,13 +89,19 @@ Esempio: metadata IdP Disponibilità dei metadata ^^^^^^^^^^^^^^^^^^^^^^^^^^ -I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso la URL *https:///metadata*, ove non diversamente specificato nel **Registro SPID**, e saranno firmate in modalita detached dall'Agenzia per l'Italia Digitale. +I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso +la URL *https:///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. Service Provider ---------------- +.. warning:: + Per la struttura dei certificati elettronici e dei Metadata dei Service Provider si rimanda alle specifiche contenute in + `Avviso AgID n29 v3 `_. + 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: .. admonition:: SI DEVE diff --git a/single-sign-on.rst b/single-sign-on.rst index 72b430e..136b7ea 100644 --- a/single-sign-on.rst +++ b/single-sign-on.rst @@ -39,8 +39,9 @@ Può essere inoltrato da un Service Provider all’Identity Provider usando il b * l'attributo ``IssueInstant`` a indicare l'istante di emissione della richiesta, in formato UTC (esempio: ``2017-03-05T18:03:10.531Z``) * l'attributo ``Destination``, a indicare l'indirizzo (URI reference) dell'Identity Provider a cui è inviata la richiesta, come risultante nell'attributo entityID presente nel metadata IdP dell'Identity Provider a cui viene inviata la richiesta - .. WARNING:: - Il valore richiesto per l'attributo ``Destination`` differisce da quanto previsto dalle specifiche SAML. + .. note:: + Il valore richiesto per l'attributo ``Destination`` differisce da quanto previsto dalle specifiche `SAML Core 2.0 `_ pagina 36. + Come reso esplicito da `Avviso AgID numero 11 `_ * l'attributo ``ForceAuthn`` nel caso in cui si richieda livelli di autenticazione superiori a SpidL1 (SpidL2 o SpidL3) @@ -83,7 +84,7 @@ Può essere inoltrato da un Service Provider all’Identity Provider usando il b *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 ```` 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 1024 bit e algoritmo di digest SHA-256 o superiore. + * nel caso del binding **HTTP POST** deve essere presente l'elemento ```` 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. .. admonition:: SI PUÒ @@ -113,6 +114,22 @@ Può essere inoltrato da un Service Provider all’Identity Provider usando il b Gli elementi ```` ```` 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 consideri le seguenti specifiche tecniche: + +- `Avviso AgID numero 15 `_ +- `Avviso AgID numero 18 `_ +- `Avviso AgID numero 18 v2 `_ + + Esempio di AuthnRequest ^^^^^^^^^^^^^^^^^^^^^^^ @@ -217,6 +234,7 @@ Esempio di Response con Assertion :language: xml :linenos: + Processamento della Response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/soggetti-aggregatori.rst b/soggetti-aggregatori.rst new file mode 100644 index 0000000..d371ade --- /dev/null +++ b/soggetti-aggregatori.rst @@ -0,0 +1,11 @@ +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: + +- `Avviso AgID numero 19 v4 `_ +- `Avviso AgID numero 22 v3 `_ +- `Avviso AgID numero 23 v2 `_ From 13fc943f3621161e9356ec3b452095cb3838a401 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Fri, 5 Feb 2021 11:23:11 +0100 Subject: [PATCH 2/6] =?UTF-8?q?Update=20index.rst:=20[Questo=20documento?= =?UTF-8?q?=20=C3=A8=20aggiornato=20all'=20Avviso=20SPID=20n.=2034.]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Alessandro Ranellucci --- index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.rst b/index.rst index 38b50e2..fe3a1c6 100644 --- a/index.rst +++ b/index.rst @@ -20,7 +20,7 @@ Identity Provider, Service Provider ed Attribute Authority mediante il protocoll 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 SPID n34** + Questo documento è aggiornato all'**Avviso SPID n. 34**. e precedenti. Indice dei contenuti From 461cd6605667c3f46852f45e3702b99554a0d4b2 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Fri, 5 Feb 2021 11:24:23 +0100 Subject: [PATCH 3/6] Update single-sign-on.rst: [si consideri / si applicano] Co-authored-by: Alessandro Ranellucci --- single-sign-on.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/single-sign-on.rst b/single-sign-on.rst index 136b7ea..3e23e64 100644 --- a/single-sign-on.rst +++ b/single-sign-on.rst @@ -123,7 +123,7 @@ Per i casi in cui il fornitore di servizi richieda una Autenticazione per i segu - Identità digitale ad uso professionale della persona fisica - Identità digitale ad uso professionale per la persona giuridica -Si consideri le seguenti specifiche tecniche: +si applicano le seguenti specifiche tecniche: - `Avviso AgID numero 15 `_ - `Avviso AgID numero 18 `_ From 2b9bc015e2e817cabdd0b494310a514f7f7828ca Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 5 Feb 2021 11:27:41 +0100 Subject: [PATCH 4/6] Aggiunto link avviso AgID n28 --- metadata.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/metadata.rst b/metadata.rst index c07d07c..df58793 100644 --- a/metadata.rst +++ b/metadata.rst @@ -7,7 +7,7 @@ Ciascuna entità presente nella federazione SPID è descritta da un file di meta La distribuzione dei metadati a tutti i soggetti è operata dall'Agenzia per l'Italia Digitale attraverso il `Registro `_. .. Warning:: - I fornitori di servizi pubblici - come identificati nell’Avviso AgID numero 28/2020 - possono continuare ad utilizzare certificati self-signed. + 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 `_ From 8a1da22fc20d790952d30da6b338b36bf69cb958 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 5 Feb 2021 21:35:21 +0100 Subject: [PATCH 5/6] avviso 25 - superamento attributo address --- attributi.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/attributi.rst b/attributi.rst index 38879f5..b307278 100644 --- a/attributi.rst +++ b/attributi.rst @@ -132,6 +132,22 @@ Il tipo sotto indicato è il valore dell’attributo ``xsi:type`` dell’element - ``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 @@ -143,6 +159,10 @@ Il tipo sotto indicato è il valore dell’attributo ``xsi:type`` dell’element * CAP; * Luogo; * Provincia. + * - Nazione + - ``domicileNation`` + - xs_string + - * - Data di scadenza identità - ``expirationDate`` - xs:date @@ -152,3 +172,6 @@ Il tipo sotto indicato è il valore dell’attributo ``xsi:type`` dell’element - xs:string - Indirizzo casella PEC + +.. warning:: + L'attributo `address` è stato sostituito dall `Avviso AgID n25 `_ From da47b2eed9835ecbc1a7d7b2471bff972baf3a83 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Tue, 9 Feb 2021 11:33:32 +0100 Subject: [PATCH 6/6] avviso 29 --- code-samples/sp-metadata-fatturazione.xml | 55 ++++ index.rst | 2 +- metadata.rst | 330 ++++++++++++++++++---- 3 files changed, 330 insertions(+), 57 deletions(-) create mode 100644 code-samples/sp-metadata-fatturazione.xml diff --git a/code-samples/sp-metadata-fatturazione.xml b/code-samples/sp-metadata-fatturazione.xml new file mode 100644 index 0000000..a685031 --- /dev/null +++ b/code-samples/sp-metadata-fatturazione.xml @@ -0,0 +1,55 @@ + + + + Denominazione Completa dell'Organizzazione s.r.l. + + + Organizzazione + + + https://organizzazione.com/it + + + + + IT12345678901 + XYZABCAAMGGJ000W + + + spid@organizzazione.com + +390123456789 + + + + + + + IT + 02468135791 + + + + Destinatario_Fatturazione + + + + + via [...] + 99 + 12345 + nome_citta + XY + IT + + + + Destinatario_Fatturazione + email@fatturazione.it + telefono_fatture + + diff --git a/index.rst b/index.rst index fe3a1c6..67224a2 100644 --- a/index.rst +++ b/index.rst @@ -20,7 +20,7 @@ Identity Provider, Service Provider ed Attribute Authority mediante il protocoll arricchiti da informazioni utili indicate con le diciture "Nota" e "Questo paragrafo ha scopo informativo e non normativo". - Questo documento è aggiornato all'**Avviso SPID n. 34**. + Questo Documento comprende le specifiche contenuto nell **Avviso AgID n° 34** e precedenti. Indice dei contenuti diff --git a/metadata.rst b/metadata.rst index df58793..9b85b6f 100644 --- a/metadata.rst +++ b/metadata.rst @@ -13,6 +13,22 @@ Ciascuna entità presente nella federazione SPID è descritta da un file di meta - `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:///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:///metadata** e saranno firmate dall'Agenzia per l'Italia Digitale. +L'accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile. + +.. Note:: + 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. + + + Identity Provider ----------------- @@ -24,7 +40,7 @@ Le caratteristiche dell'Identity provider sono definite attraverso metadata conf * ``entityID`` indicante l'identificativo (URI) dell'entità univoco in ambito SPID - * L'elemento ```` specifico che contraddistingue l'entità di tipo Identity Provider deve riportare i seguenti attributi: + * L'elemento ```` 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``) * ``WantAuthnRequestSigned``: attributo con valore booleano che impone ai Service Provider che fanno uso di questo Identity provider l'obbligo della firma delle richieste di autenticazione; @@ -32,10 +48,10 @@ Le caratteristiche dell'Identity provider sono definite attraverso metadata conf all'interno di ```` devono essere presenti: * l'elemento ```` 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 ```` che contiene 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) + * l'elemento ```` riportante l'attributo: - * ``format``, indicante il formato ``urn:oasis:names:tc:SAML:2.0:nameidformat:transient`` come quello supportato per l'elemento di ```` utilizzato nelle richieste e risposte SAML per identificare il *subject* cui si riferisce un'asserzione + * ``format``, indicante il formato ``urn:oasis:names:tc:SAML:2.0:nameidformat:transient`` come quello supportato per l'elemento di ```` utilizzato nelle richieste e risposte SAML per identificare l'identificativo del soggetto (*subject id*) cui si riferisce un'asserzione * uno o più elementi ```` che specificano l'indirizzo del Single Sign-On Service riportanti i seguenti attributi: @@ -86,72 +102,283 @@ Esempio: metadata IdP :linenos: -Disponibilità dei metadata -^^^^^^^^^^^^^^^^^^^^^^^^^^ +Service Provider +---------------- -I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso -la URL *https:///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. +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 ```` deve essere presente il seguente attributo: -Service Provider ----------------- + * entityID (1 occorrenza) - Attributo valorizzato con l’Entity id, + così come riportato nell’estensione commonName 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 Entity id. -.. warning:: - Per la struttura dei certificati elettronici e dei Metadata dei Service Provider si rimanda alle specifiche contenute in - `Avviso AgID n29 v3 `_. +* Deve essere presente l'elemento ```` 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 ```` 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 l’elemento ```` riportante i seguenti attributi: -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: + * ``protocolSupportEnumeration``: che enumera, separati da uno spazio, gli URI associati ai protocolli supportati dall’entità (poiché si tratta di un’entità SAML 2.0, deve indicare almeno il valore del relativo protocollo: ``urn:oasis:names:tc:SAML:2.0:protocol``); + * ``AuthnRequestSigned``: valorizzato ``true`` attributo con valore booleano che esprime il requisito che le richieste di autenticazione inviate dal Service Provider siano firmate; -.. admonition:: SI DEVE +* Deve essere presente almeno un elemento ```` 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: - * Nell'elemento ```` deve essere presente il seguente attributo: + * ``index`` che può assumere valori unsigned; + * ``Binding`` posto al valore ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST``; + * ``Location`` URL endpoint del servizio per la ricezione delle risposte; + + In particolare il primo di questi elementi (o l’unico elemento riportato) deve obbligatoriamente riportare: + + * l’attributo ``index`` posto al valore ``0``; + * l’attributo ``isDefault`` posto al valore ``true``; + +* Deve essere presente almeno un elemento ```` indicante l'indirizzo del SingleLogoutService e riportante i seguenti attributi: + + * ``Location`` URL endpoint del servizio per la ricezione delle richieste di Single Logout; + * ``Binding`` che può assumere uno dei valori + + * ``urn:oasis:names:tc:SAML:2.0:bindings:SOAP`` + * ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`` + * ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`` + + ed opzionalmente l'attributo: + + * ``ResponseLocation``, URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout. + + +* Organization (1 occorrenza) — Contiene vari tag, ciascuno dei quali + ripetuto almeno una volta valorizzato in lingua italiana, più + occorrenze facoltative localizzanti il medesimo nome in ulteriori + lingue (identificate mediante l’attributo xml:lang, obbligatoriamente + presente in tutti i tag figli): + + - OrganizationName (1 o più occorrenze) — Denominazione – *completa + e per esteso* e con il corretto uso di minuscole, maiuscole, + lettere accentate e altri segni diacritici – del SP, così come + riportata nell’estensione organizationName del certificato + elettronico del SP (esempio: “Agenzia per l'Italia Digitale”). + + - OrganizationDisplayName (1 o più occorrenze) — Denominazione del + SP, eventualmente in forma abbreviata (senza + esplicitare gli eventuali acronimi) con il corretto utilizzo + delle minuscole e maiuscole (esempio: “AgID”). Durante la fase di + autenticazione, gli IdP avvisano l’utente dell’invio degli + attributi al SP, visualizzando il valore di questo tag per + indicare il soggetto richiedente. + + - OrganizationURL (1 o più occorrenze) — Contiene l’ url di una + pagina del sito web del SP relativa al servizio di autenticazione + o ai servizi accessibili tramite essa, i cui contenuti sono + localizzati nella lingua specificata dal proprio attributo + xml:lang. + +* ContactPerson (1 o 2 occorrenze) — Tag utilizzato per veicolare le + informazioni per contattare il soggetto cui il metadata afferisce. + Ogni occorrenza è dotata dei seguenti attributi: + + - contactType — L’occorrenza *obbligatoria* di ContactPerson è + valorizzata con other; l’ulteriore occorrenza, obbligatoria per i + soli SP privati, è valorizzata con billing. + +.. + + L’occorrenza di ContactPerson con l’attributo contactType valorizzato + come other contiene i seguenti tag (*namespace* md): + +- Extensions (1 occorrenza *obbligatoria*) — Contenente almeno uno dei + seguenti tag (tutti con *namespace* spid): + + 1. IPACode — Presente *solo* per il SP *pubblico*, è valorizzato con + il codice ipa dell’Ente. + + 2. VATNumber — Obbligatorio per il SP *privato* dotato di partita iva + (altrimenti facoltativo), è valorizzato comprensivo del codice ISO + 3166-1 α-2 del Paese (senza spazi). - * ``entityID``: indicante l'identificativo univoco (un URI) dell'entità; + 3. FiscalCode — Obbligatorio per il SP *privato* non dotato di + partita iva (altrimenti facoltativo), è valorizzato con il codice + fiscale del SP. - * Deve essere presente l'elemento ```` 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 ```` 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 1024 bit e algoritmo di digest SHA-256 o superiore; - * Deve essere presente l’elemento ```` riportante i seguenti attributi: + 4. Public — Tag vuoto, *obbligatorio* per il SP pubblico o, - * ``protocolSupportEnumeration``: che enumera, separati da uno spazio, gli URI associati ai protocolli supportati dall’entità (poiché si tratta di un’entità SAML 2.0, deve indicare almeno il valore del relativo protocollo: ``urn:oasis:names:tc:SAML:2.0:protocol``); - * ``AuthnRequestSigned``: valorizzato ``true`` attributo con valore booleano che esprime il requisito che le richieste di autenticazione inviate dal Service Provider siano firmate; +.. - * Deve essere presente almeno un elemento ```` 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: + *in alternativa*, - * ``index`` che può assumere valori unsigned; - * ``Binding`` posto al valore ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST``; - * ``Location`` URL endpoint del servizio per la ricezione delle risposte; +* Private — Tag vuoto, *obbligatorio* per il SP privato. - In particolare il primo di questi elementi (o l’unico elemento riportato) deve obbligatoriamente riportare: +- Company (0 o 1 occorrenze) — Se presente, è valorizzato come il tag + OrganizationName contenuto nel tag Organization. - * l’attributo ``index`` posto al valore ``0``; - * l’attributo ``isDefault`` posto al valore ``true``; +- 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. - * Deve essere presente almeno un elemento ```` indicante l'indirizzo del SingleLogoutService e riportante i seguenti attributi: +- 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). - * ``Location`` URL endpoint del servizio per la ricezione delle richieste di Single Logout; - * ``Binding`` che può assumere uno dei valori + +Certificati +^^^^^^^^^^^ + + +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: + +1. Nel campo **SubjectDN**: + + a. **commonName** (oid `2.5.4.3 `__) — + Entity id del SP, così come riportato nell’attributo entityID del + tag xml del metadata del SP. + + b. **organizationName** (oid `2.5.4.10 `__) — Denominazione + *completa e per esteso* del SP, così indicata nei pubblici + registri e come riportata nel tag xml del + metadata del SP (esempio: “Comune di Forlì” e *non* “COMUNE DI FORLI'”); + + c. **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, “VAT IT-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. + + d. **countryName** (oid `2.5.4.6 `__) — + il codice ISO 3166-1 del Paese ove è situata la sede legale + del SP (esempio: “IT”); + + e. **localityName** (oid `2.5.4.7 `__) — + il nome completo della città ove è situata la sede legale del SP + (esempio: *Forlì* e **non** *Forli'*). + +2. Nel campo **CertificatePolicies**: + + **policyIdentifier** — contenente almeno uno dei seguenti + identificatori: + + - **SP pubblici** — spid-publicsector-SP (oid + `1.3.76.16 `__.\ **4.2.1**); + + - **SP privati** — spid-privatesector-SP (oid + `1.3.76.16 `__.\ **4.3.1**). + +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**. + + +Informazioni obbligatorie per la fatturazione +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - * ``urn:oasis:names:tc:SAML:2.0:bindings:SOAP`` - * ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`` - * ``urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`` - - ed opzionalmente l'attributo: - - * ``ResponseLocation``, URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout. + 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, NumeroCivivo + (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). - * Deve essere presente uno o più elementi ```` a descrizione dei set di attributi richiesti dal Service Provider, riportante: + - 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. - * l’attributo ``index``, indice posizionale dell’elemento relativo all'i-esimo servizio richiamato dalla AuthnRequest mediante l’attributo ``AttributeConsumingServiceIndex``; - * l’elemento ````, riportante l’identificatore dell'i-esimo set minimo di attributi necessari per l’autorizzazione all’accesso (per la massima tutela della privacy dell'utente il Service Provider deve rendere minima la visibilità dei servizi effettivamente invocati; in questa logica occorre rendere ove possibile indifferenziate le richieste relative a servizi che condividono lo stesso set minimo di attributi necessari per l'autorizzazione); -.. admonition:: SI PUÒ +Esempio: Contatti metadata SP per Fatturazione +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - * È consigliata la presenza di un elemento ```` a indicare l’organizzazione a cui afferisce l’entità specificata, riportante gli elementi: +.. literalinclude:: code-samples/sp-metadata-fatturazione.xml + :language: xml + :linenos: - * ```` indicante un identificatore language-qualified dell’organizzazione a cui l’entità afferisce; - * ```` riportante in modalità language-qualified la URL istituzionale dell’organizzazione. Esempio: metadata SP ^^^^^^^^^^^^^^^^^^^^ @@ -159,12 +386,3 @@ Esempio: metadata SP .. literalinclude:: code-samples/sp-metadata.xml :language: xml :linenos: - -Disponibilità dei metadata -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -I metadata dei Service Provider saranno disponibili per tutte le entità SPID federate attraverso la URL **https:///metadata** e saranno firmate dall'Agenzia per l'Italia Digitale. -L'accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile. - -.. Note:: - 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.