Service Provider per aggregazione di Enti Pubblici

Buongiorno a tutti.

Nella mia azienda, stiamo sviluppando un applicativo rivolto ai cittadini di più Comuni, ai quali dobbiamo dare la possibilità di autenticarsi ed accedere tramite SPID.

In questo scenario, di conseguenza, la mia azienda (quindi un privato) è Service Provider per Enti Pubblici diversi, tutti ospitati su una stessa applicazione (o, in altre parole, aventi tutti come riferimento un unico indirizzo web principale per l’accesso).

Non mi è chiaro se, in questa situazione, la fase di accreditamento preveda che la mia azienda sia tenuta a rendere disponibile un solo metadata (cioè un metadata associato all’applicativo) oppure se è necessario fornire un metadata per ogni ente configurato; analogamente, la stessa domanda vale per quanto riguarda la convenzione da firmare e da inviare (ne basta una sola firmata ed inviata dalla mia azienda oppure ne è necessaria una per ente, firmata da una persona dell’ente stesso?).

Grazie in anticipo per il supporto.

1 Mi Piace

Ciao @robich,
quindi voi agite come fornitore di PA, ciò vuol dire che il metadata deve essere comunicato dalla PA così come la convenzione quindi n metadata e convenzioni. Oggettivamente architetterei i servizi in maniera separata per PA a meno che non si tratti di un portal di servizi per tutte le PA. Per non disorientare l’utente spero che il riferimento all’amministrazione che utilizza il servizio sia specificato sul vostro applicativo, magari con un logo e magari impostando il dns del servizio su un host della PA stessa. Poi tecnicamente lo IAM che sta sopra il servizio può essere non riferito alla singola PA quindi sui metadata, per intenderci, l’AssertionConsumerService potrà essere comune.

Buona giornata

Umberto Rosini
Agenzia per l’Italia Digitale

Buongiorno, anche noi abbiamo un problema simile, lo espongo qui perchè credo sia attinente al thread. Se volete posso cancellare il messaggio e aprirne uno nuovo.

Abbiamo sviluppato un gestionale per le scuole e dovremmo dare accesso ad alcuni dati ai genitori che però possono avere figli in più istituti. Da quello che ho capito dalla risposta, siccome ogni istituto avrebbe metadati diversi, il genitore dovrebbe accedere ai dati di ogni scuola separatamente facendo più login con lo SPID, è corretto?

Pensavamo di utilizzare spid-simplesamlphp. Tenendo conto che le scuole potrebbero essere centinaia e idealmente il server fisico dovrebbe essere uno solo, quale è il setup consigliato? spid-simplesamlphp può essere utilizzato con configurazioni multiple o dobbiamo creare un server virtuale per ogni scuola?

Grazie e buona giornata.

Paolo

1 Mi Piace

Ciao, @umbros, innanzitutto grazie della risposta.

Provo a spiegarmi meglio qui sotto, prendendo spunto dalle tue osservazioni.

Oggettivamente architetterei i servizi in maniera separata per PA a meno che non si tratti di un portal di servizi per tutte le PA.

Si tratta di un portale per i comuni nostri clienti che decidono di aderire al servizio.

Per non disorientare l’utente spero che il riferimento all’amministrazione che utilizza il servizio sia specificato sul vostro applicativo, magari con un logo e magari impostando il dns del servizio su un host della PA stessa.

L’utente che accede al portale deve per prima cosa scegliere il comune a cui accedere, per cui ti confermo che il riferimento all’amministrazione è chiaro, benché la URL di accesso ed il dominio siano gli stessi per tutti.

Poi tecnicamente lo IAM che sta sopra il servizio può essere non riferito alla singola PA quindi sui metadata, per intenderci, l’AssertionConsumerService potrà essere comune.

Questo forse è il punto chiave: da quello che dici, mi par di capire che a livello puramente tecnico la nostra soluzione potrebbe stare in piedi con un unico metadata, che rimanda al servizio, ed il problema sia più che altro di tipo amministrativo.

Un ulteriore dubbio però mi è venuto leggendo qui https://www.spid.gov.it/sei-una-pubblica-amministrazione e qui http://www.agid.gov.it/sites/default/files/documentazione/spid-avviso-n6-note-sul-dispiegamento-di-spid-presso-i-gestori-di-servizi-v1.pdf.

Da quello che leggo, infatti, la questione mi pare diversa da come l’avevo posta, ovvero mi pare che, nello scenario proposto, la registrazione del metadata e la relativa convenzione siano tipicamente sempre un’attività a carico dell’ente, che sceglie come aggregare i servizi (o meglio, definisce i cosiddetti nodi cluster) e che modifica poi il metadata nel momento in cui un nuovo servizio (per esempio quello erogato dalla mia azienda) viene aggiunto.
In questo scenario, l’interfacciamento con AGID è di fatto sempre a carico della PA e non del fornitore.
Se così fosse, la questione si sposterebbe notevolmente da quanto da me ipotizzato in precedenza, in quanto tutta la fase di autenticazione sarebbe per forza esterna al nostro applicativo (URL su host della PA stessa, coem dicevi tu), ed il nostro applicativo verrebbe solo richiamato a posteriori, ad autenticazione completata.

Ho capito bene?

Ti ringrazio ancora per il supporto.

Buongiorno, ritorno sul mio post di qualche giorno fa.
Qualcuno sa darmi un feedback sul mio ultimo commento?

Grazie,
Roberto

Ciao @robich, non sono la fonte “ufficiale” ma provo a risponderti con quello che so e che abbiamo fatto e sta funzionando, visto che siamo più o meno nelle vostre condizioni.
Il metadata è unico per ogni singolo ente che aderisce a SPID e, almeno attualmente, deve esse pubblicato in https su una url attribuibile all’ente stesso (es: spid.comune.xxxx…yy.it), quindi se hai N enti, devi pubblicare e comunicare ad AgID N metadata.
In tutti gli N metadata (nell’attributo AssertionConsumerService) puoi mettere la stessa URL della tua implementazione unica dell’IAM sul portale dove gestisci tutti i i tuoi comuni e fare l’autenticazione secondo le linee guida di SPID, poi puoi passarti i dati autenitcati da SPID, localmente, al portale specifico dell’ente.
Quindi, l’ente pubblica i metadata, aderisce e firma la convenzione, tu implementi l’interfacciamento con SPID e fai l’autenticazione.
Spero di esserti stato utile, @umbros correggimi se ho sbagliato qualcosa…
Ciao
Federico

Grazie @FedericoA, spiegazione chiarissima e perfettamente calata sul nostro scenario.
Per il momento direi che è proprio quello che mi serviva sapere per capire come affrontare la questione più che altro dal punto di vista burocratico.

Grazie ancora,
Roberto

Ciao @robich,
non posso che confermare quanto detto da @FedericoA che ringrazio.

Umberto Rosini
Agenzia per l’Italia Digitale

Ciao a tutti mi associo perché anche io ho il solito problema, sto sviluppando un applicazione service provider per enti pubblici ed in previsione di effettuare una gestione efficiente ed efficacie di numero arbitrario di Service Provider SPID per conto di altrettanti enti pubblici, è sorta l’esigenza di raggruppare tutti i SP sotto un unica url afferente alla nostra azienda, discriminando i diversi enti, per conto dei quali facciamo da SP, attraverso la radice del path; la url sarà dunque così composta:

https://spid.xxx.it/n201753/

Dove il dominio (parte fissa) spid.xxx.it è un dominio della nostra azienda sul quale abbiamo pieno controllo e che possiamo gestire in piena autonomia ed il path (parte variabile) n201753 è l’identificativo dell’ente.

Prima di procedere con questo adeguamento strutturale, Vi chiediamo conferma sulla possibilità di utilizzare questa soluzione ed in caso contrario di segnalarci eventuali problematiche.

Buongiorno, anche io ho una situazione per certi versi analoga a quella @filippo.ermini: siamo una società di consulenza per gli enti locali, abbiamo sviluppato un unico portale multi-tenant, che offre dei servizi al cittadino dei vari enti,ove vorremmo integrare l’autenticazione con spid.

Il portale multitenant è ospitato su un nostro dominio e i singoli entry point degli enti hanno una url tipo

  • nomeente.nostraazienda.it

Attualmente nessuno dei domini dispone di certificato ssl, nell’immediato, sarebbe sufficiente UN UNICO certificato ssl wiildcard a copertura di tutti i sottodomini della nostra azienda che puntano ai vari entry point?

Grazie, buona giornata

Buongiorno, la soluzione a questa problematica è la seguente:

  • Sistema di Access Management del fornitore che va ad implementare SPID sull’applicazione fornita alla PA
  • L’applicazione fornita alla PA dovrà anche essere in grado di agganciarsi ad altri sistemi di access management SPID
  • Ogni PA ha un suo metadata e certificato di signing delle asserzioni
  • Gestione di più certificati di signing uno per PA che utilizza il sistema di access management
  • Gestione dei log separata per PA
  • Il sistema di Access Management potrà essere utilizzato solo dalle PA
    Non un certificato wildcard ma, come definito anche da CERT-PA, la possibilità di utilizzare certficati Let’s Encrypt su ogni specifico dominio di 3 livello.

Verrà rilasciato un avviso apposito su questo tema fornitori/pa

Umberto Rosini
Agenzia per l’Italia Digitale

1 Mi Piace

Gentilissimi,
Mi aggancio ai vari quesiti per sottoporre alla vostra attenzione il nostro caso.
La Regione Calabria ha commissionato la realizzazione di un nodo cluster, del tutto in linea con le prescrizioni di cui all’Avviso Nr. 6 del 29/07/2016 “Note sul Dispiegamento di Spid presso i gestori dei Servizi”.
Il nodo Cluster www.regione.calabria.it metterà a disposizione dei cittadini un insieme di servizi, basati sulla strutturazione interna dell’ente. Tra questi è stato prevista l’istituzione di un nodo denominato Ecositema Calabria Sanità.
A breve si prevede l’istituzione di ulteriori nodi afferenti al mondo dei tributi e lavoro.
Intenzione della Regione, per come chiarito, è l’istituzione di un nodo cluster configurandosi l’ipotesi di regione Calabria/gestore di più servizi o service provider, il cui dispiegamento avrà le seguenti caratteristiche:
A) Presenza di più nodi di erogazione (per il momento quello di specifico interesse e di immediata istituzione è da riferire al nodo Ecosistema Calabria Sanità) distribuiti geograficamente;
B) Servizi orientati al cittadino aggregati in classi in base al set di attributi per i quali si chiede la certificazione e nello specifico Classe Salute (Servizio Scelta e Revoca, Consultore, R@ro, Vaccinazioni, Esenzioni), Attributi richiesti per la Classe Salute “Codice Fiscale”, e altre classi che nel presente esempio al momento non rilevano.

Nel caso in esame si evidenzia che i servizi previsti ed afferenti al nodo Ecosistema Salute di cui alla Classe Salute indicata saranno forniti tramite un nodo in cloud.

In sostanza il nodo geografico, con ambiente applicativo predisposto per l’erogazione dei servizi menzionati, è rappresentato da un application server che sarà raggiunto dal cittadino tramite redirect dal nodo “servizi.sanita.regione.calabria.it” ad un record DNS del tipo www.servizisanitaregionecalabria.it gestito dalla nostra azienda (record non confacente con il dominio del Service Provider se non tramite puntamento dedicato).

In funzione di quanto addotto ed al fine di rispettare tutte le condizioni utili ad implementare il servizio di autenticazione si chiede conferma delle seguenti affermazioni:

  1. tutti i nodi afferenti al Service Provider ed interessati dall’esempio devono essere certificati SSL (SSL WildCard) a partire dal service provider www.regione.calabria.it, ai singoli nodi geografici tra cui servizi.sanita.regione.calabria.it (con DNS dedicato) fino al nodo servizisanitaregionecalabria.it (portale raggiunto tramite puntamento dedicato sul quale deteniamo massimo controllo)
  2. la procedura di creazione del metadato, secondo le specifiche di cui all’Avviso 6, può interessare anche un singolo nodo geografico e nello specifico il nodo https servizi.sanita.regione.calabria.it oltre al nodo cluster www.regione.calabria.it
  3. per l’eventuale attivazione di ulteriori servizi, a distanza di tempo, fatta salva la creazione di ulteriori metadati, andranno pur sempre dettagliati i servizi e gli attributi richiesti di riferimento.
  4. se non si hanno chiari i servizi, le classi e gli attributi di riferimento per tutti i servizi di cui si prevede erogazione (distinti per classi e caratterizzati da specifci attributi) non è ipotizzabile avviare una procedura di certificazione e di adesione a SPID ai fini della creazione di un nodo cluster.

Vi ringraziamo sin da ora dell’interesse che vorrete mostrare.

Distinti saluti.

Ciao @FedericoA,
immaginando una configurazione Shibboleth, mi permetto di aggiungere che, in questo caso, ogni AssertionConsumerService dovrebbe essere specifico per PA nella URL (path) o nel dominio (anche di terzo livello) utile per discriminare la richiesta che va firmata con il certificato corrispondente alla PA.

@umbros sei d’accordo in merito?

Gentilissimo @umbros,
Ho letto di un webinar (http://eventipa.formez.it/node/157545) per il prossimo 25/09 al quale parteciperemo con piacere.
Sollevo, fiducioso in una risoluzione tempestiva, la seguente problematica:
Abbiamo prodotto un metadata, richiedendone validazione, mediante implementazione del Docker “Spid Auth Docker” che configurato restituisce nella sezione SignatureValue un hash di firma dedicato, funzione dell’utilizzo dei certificati Saml di riferimento.

Nonostante il metadata risulti firmato otteniamo dallo staff tecnico Spid informazioni circa “la mancata corrispondenza fra hash della firma e il contenuto del documento”.
Abbiamo utilizzato al riguardo anche tutti i tool di firma suggeriti per ambienti Linux (Spid Metadata Signer) ma non riusciamo a venirne a capo in quanto il file ci risulta già firmato.
Tra l’altro utilizzando il docker suggerito si ritiene che non sia necessario ricorrere ad ulteriori strumenti di firma! Ma a questo punto ci dobbiamo ricredere.
Avremmo la necessità di essere supportati da un punto di vista tecnico.
Conoscere laddove possibile se sussistono prima dell’invio strumenti di validazione e comprendere a questo punto quale parte del metadata è corrotta o non corrispondente al resto dei contenuti.
Quale canale è il più suggerito? È possibile utilizzare e sollevare la problematica accennata su mail spid.tech@agid.gov.it?

Grazie mille del supporto.

Buongiorno,
ha scaricato l’ultima versione del docker? Una problematica può essere se, viene generato un metadata dal sp auth docker e copiato su un altro file questo si corrompe.

Umberto Rosini
Agenzia per l’Italia Digiale

Grazie @umbros abbiamo verificato la versione del docker ed effettivamente era datata. Le siamo grati. Come possiamo verificare che il metadata è compliant e che tutto è ok prima del prossimo invio? Allego link da cui poter prender visione, se le è possibile, del nuovo file: https://spid.regione.calabria.it/metadata.

Tra le cose che non riusciamo a fare attualmente troviamo

  • l’inserimento all’interno della sezione: </md:KeyDescriptor><md:SingleLogoutService dei metodi di binding di nostro interesse (nel nostro caso intendiamo fare affidamento solo su HTTP-Redirect).

  • a settare Location di logout

  • a gestire binding e location dello stesso AssertionConsumerService.

Esiste un file di configurazione dedicato? Possiamo forzare tali attributi?

Grazie mille.

Ciao,
ho fatto controllare dal supporto tecnico ed è tutto ok,
per eventuali modifiche potete lavorare direttamente nelle configurazioni di shibboleth2.xml all’interno del container oppure modificare il metadata e rifirmarlo magari utilizzando spid-metadata-signer.

Fammi sapere

Umberto Rosini
Agenzia per l’Italia Digitale

Grazie @umbros! Ti aggiorniamo appena possibile!

Buona giornata e a più tardi!

Ciao, seguendo il suggerimento di @umbros abbiamo modificato il file shibboleth2.xml.tpl nella directory etc/shibboleth. Avviamo il composer e viene creato il container ma il file metadata non cambia i parametri SingleLogoutService -> location e AssertionConsumerService -> location.
Mi mantiene quelli di default del docker.
Dobbiamo modificare qualche altro file per poter personalizzare le location dei due tag?
Grazie e buon lavoro!

Una banale domanda, ma un comune può svolgere l’attività senza l’ausilio totale del fornitore?