@umbros stiamo ricevendo molte richieste di enti che ci chiedono di aggiungere al nostro metadata quello di altri fornitori. Gli enti con cui abbiamo a che fare sono piccoli e non fanno nulla in autonomia, non espongono i metadata dei servizi.
Resta valido quanto scritto in questo thread, ovvero che tra i vari fornitori uno si elegge a “manutentore dei metadata” degli altri fornitori?
Se uno dei fornitori coinvolti è un soggetto aggregatore cambia qualcosa?
grazie!
Credo che @umbros non lavori più come minimo da due anni nel Team per l’innovazione digitale, forse tre (almeno, qui sul Forum credo non risponda dal 2018).
Ritorno sull’argomento, il merge dei metadati è una operazione che sta diventando frequente e così com’è a mio parere è di difficile gestione.
Innanzitutto gli enti spesso non sanno nemmeno di avere già un metadato e reperirlo è a volte difficile, considerato che non c’è un registro dei metadati o sbaglio?
Inoltre che succede se un fornitore manda un aggiornamento del metadato non sapendo che un altro fornitore nel frattempo ha aggiunto i suoi servizi? Se il metadato viene accettato il secondo fornitore perde l’accesso?
Occorre a mio parere che AGID predisponga un sistema di onboarding centralizzato come proposto all’inizio di questo thread, ogni fornitore di servizi potrebbe segnalare gli url e i certificati, compito di AGID creare il metadato e propagarlo ai vari IDP.
Tutto sarebbe più semplice.
Grazie.
Beh, esiste questo servizio Registro SPID - Service Providers che fornisce l’elenco dei fornitori di servizi pubblici che hanno aderito a SPID. Non è proprio un metadataprovider, ma include anche il codice IPA che alla luce delle recenti indicazioni riportate nell’avviso SPID 29 deve essere incluso nei metadati, quindi qualche verifica preliminare si può fare.
Non dovrebbe essere il fornitore a inviare i metadati, ma il referente tecnico SPID della PA che deve essere indicato esplicitamente al momento della richiesta di adesione. E’ quindi la PA che deve avere il controllo del file di metadati, non il fornitore.
Al netto del sistema di onboarding e della gestione manuale del merge di metadati lo schema è esattamente quello. Il controllo del file di metadati deve essere effettuato dalla PA.
Saluti,
Angelo.
Tutto giusto se gli enti sapessero esattamente cosa è un metadato, cosa deve contenere, come va creato, come va firmato… se…
Insisto con questo argomento, ho attivato alcuni SPID che mi sono stati respinti da AGID perchè un metadato era già stato inviato e quindi occorre fare il merge.
In questo caso AGID fornisce solo l’entityId in suo possesso e null’altro, il cliente spesso non sa come reperire il metadato, a questo punto che si fa?
Non sarebbe più semplice che AGID fornisca in risposta il metadato in suo possesso in modo che si possa agevolmente fare il merge?
Ammesso che qualcuno di AGID legga questo forum (cosa di cui comincio a dubitare), è possibile avere un risposta?
Grazie.
La tua proposta è molto ragionevole e condivisibile. Suggerirei di fare una istanza formale via PEC, se non danno seguito alle richieste gia email (sicuramente ci sarà un sovraccarico di lavoro in questi mesi).
Riguardo questo punto:
Non sarebbe più semplice che AGID fornisca in risposta il metadato in suo possesso in modo che si possa agevolmente fare il merge?
I metadati sono disponibili a questo url: https://registry.spid.gov.it/metadata/sp/[codice_ipa].xml
Buongiorno,
riprendo questo thread perchè anche nella nostra PA è successa una cosa simile a quanto già scritto. Metadata erogato da fornitore e adesso nuovo servizio, con altro fornitore, con l’esigenza di modificare il metadata originale.
Vorrei chiedere se la seguente procedura è ancora valida:
Mi confermate tutti i punti?
grazie
Dimentichi:
Nuova chiave pubblica (Certificato x509) da inserire all’interno di un nuovo elemento KeyDescriptor (la coppia di chiavi pubblica/privata deve essere generata in accordo all’Avviso n°29) e associata la nuovo servizio (non è obbligatorio, ma per motivi di sicurezza è consigliatissimo che 2 distinti fornitori non utilizzino le stesse chiavi).
Eventuale nuovo set di attributi (Tag AssertionConsumingService) associato al nuovo servizio (non è obbligatorio, ma è consigliabile non “riciclare” AssertionConsumingService già presenti, in modo da evitare che in futuro eventuali modifiche facciano pestare i piedi fra i due servizi).
Se il metadata è molto vecchio, è possibile che sia da riallineare con i requisiti del citato Avviso SPID n°29, nella parte relativa al tag ContactPerson e ai suoi sotto elementi.
Per il resto, la tua descrizione è corretta.
Prima di inviare il metadata ad AgID puoi testarne la correttezza utilizzando spid-sp-test oppure l’Ambiente Demo SPID
Grazie! Commento molto utile.
Sugli attributi non avevo dubbi nel fare un nuovo set con index diverso.
Sul testare mi è difficile perché le implementazioni dei vari SP sono in campo a due soggetti privati moloto articolati e noi facciamo solo da raccordo e coordinamento. Quindi devo fare il nuovo metadata, coordinandomi con loro, e poi sottoporre ad AGID sperando che tutto vada bene.
In sintesi: gli endpoint non sono da noi e per me sono black box.
Però se hai altri suggerimenti, ti prego di mandarmeli. Già questi sono stati molto utili per la parte dei certificati.
Come scritto nel post precedente , mi riferivo alla correttezza del metadata creato, non all’implementazione.
In estrema sintesi, si tratta di:
Non ha sostanzialmente nulla a che vedere con la logica e le funzionalità che stanno dietro gli endpoint.
In merito alla chiave utilizzata per la firma, se è la PA che fa il merge in un unico metadata, il certificato è uno solo, corretto?
grazie
Se stiamo parlando della firma del metadata (elemento Signature), il processo di firma dei file xml ammette sempre e solo 1 firma.
Sì mi riferisco alla firma del metadata. Scusa l’ignoranza ma ci sono altre firme?
Approfitto per chiedere una delucidazione tecnica. L’avviso 29 prevede che il certificato di firma abbia delle specifiche estensioni X.509. Che tool utilizzate per inserire queste estensioni?
grazie
Sia le richieste inviate agli IDP (AuthnRequest), che le loro risposte (Response) sono di fatto dei file xml firmati.
Per questo motivo, se segui il mio consiglio di avere coppie di certificati distinti per fornitori distinti, dovrai girare la “seconda coppia” di certificati al fornitore del secondo servizio: per consentirgli di firmare le AuthnRequest per tale servizio.
Per generare i certificati puoi usare (o far usare) questo tool.
Ok grazie. Quindi nell’ipotesi di avere 2 fornitori, ho 3 coppie di chiavi: una per firmare il metadata, una per il fornitore n.1 e una per il fornitore n. 2.
Le chiavi pubbliche dei fornitori sono esplicitate nel tag <SPSSODescriptor> mentre quella di firma è nella parte <Signature>
Guardando le regole tecniche mi sembra che la cosa dovrebbe andare.
Ho visto inoltre il tool che mi hai segnalato (peraltro indicato nelle regole tecniche) e mi sembra che faciliti molto la creazione dei certficati e coppie di chiavi.
Grazie molte
Due appunti:
<Keydescriptor>, contenuti all’interno del tag <SSODescriptor> e a loro volta aventi dei sotto tag. Avendo già l’esempio del vecchio metadata basta copiare ed rincollare di seguito il tag <Keydescriptor>, modificando il contenuto della chiave (la stringa che inizia per MII…)