search

italia / spid-shibboleth-proxy-docker

SPID authentication proxy based on Shibboleth service provider
European Union Public License 1.2
22 stars 11 forks source link

Azure: problema metadata IdP #9

Closed sweeperpm closed 5 years ago

sweeperpm commented 5 years ago

Buongiorno, abbiamo utilizzato SPID AUTH DOCKER per realizzare un service provider in Microsoft Azure modalità PaaS. Durante un riavvio del container in Azure abbiamo notato che il container ha smesso di funzionare con gli identity provider istituzionali, funzionando solamente con l’identity provider di test messo a disposizione da Agid. (https://idp.spid.gov.it). L’errore che veniva fornito da SAML era piuttosto chiaro: “unable to locate metadata for identity provider”. Indagando nei log di shibboleth (file shibboleth.log) abbiamo notato che il file xml dei metadata degli identity provider non veniva creato e comparivano diversi warning sul fatto che venisse utilizzata una configurazione shibboleth alla versione 2 che non è più supportata.

Il file incriminato sembra essere /etc/shibboleth/shibboleth2.xml.tpl <MetadataProvider type="XML" validate="true" uri="https://registry.spid.gov.it/metadata/idp/spid-entities-idps.xml" backingFilePath="spid-entities-idps.xml" reloadInterval="3600"> <MetadataFilter type="Signature" certificate="/opt/shibboleth-sp/metadata/registry.pem"/> </MetadataProvider> <MetadataProvider type="XML" validate="true" file="/opt/shibboleth-sp/metadata/idp.spid.gov.it.xml" id="https://idp.spid.gov.it" />

In particolare la parte di Signature.

È un problema noto? È veramente legato alla versione non più supportata?

Grazie e cordiali saluti. Fabio Scubla

psmiraglia commented 5 years ago

Salve @scubla88, il problema e' noto ed e' dovuto al fatto che il certificato con cui e' firmato il "metadata di metadata" (https://registry.spid.gov.it/metadata/idp/spid-entities-idps.xml) e' stato aggiornato.

Nel branch devel il problema dovrebbe essere stato risolto nel commit d21b4f785 dove oltre all'aggiornamento del certificato e' stata aggiornata anche la configurazione di Shibboleth SP in modo da allinearsi al branch 3.x. Inoltre, sono stati "portati fuori" i file per la configurazione del logging e delle security policy.

Nei prossimi giorni dovremmo passare tutto in master e rilasciare una nuova versione dell'immagine Docker. Nel frattempo, potreste provare a utilizzare l'immagine presente nel branch devel e vedere se si risolvono le problematiche che avete riscontrato.

sweeperpm commented 5 years ago

Buonasera @psmiraglia , ringrazio per la tempestiva risposta. Riuscite a comunicarci quando verrà effettuato il rilascio in master? Dovremo schedulare l'attività per l'aggiornamento in ambiente di produzione.

Grazie, Fabio Scubla

psmiraglia commented 5 years ago

Suggerisco di fare watch del repository [1] in modo da ricevere in real-time le notifiche riguardo le ativita'. Avete per caso provato la versione in devel?

psmiraglia commented 5 years ago

Buonasera @scubla88, abbiamo appena rilasciato la versione 1.0.0. Fra le varie cose, questa versione risolve le problematiche da voi riscontrate.

NOTA: La versione 1.0.0 e' una major release [1] e pertanto non e' retro compatibile con le versioni della serie 0.x.

sweeperpm commented 5 years ago

Buongiorno @psmiraglia , grazie per l'assistenza. Al momento abbiamo aggiornato il certificato presente nella versione che avevamo, in quanto la major release non è retro compatibile, e ora funziona correttamente. Ho notato che quello attuale scade il prossimo anno, quindi presumo che sarà da aggiornare ogni anno, è corretto? In modo tale da organizzare l'attività e non creare un disservizio.

Vi segnalo che l'unico IdP che dà problema è quello di TIM che riporta il seguente errore: "Si è verificato un errore imprevisto. Pagina non trovata. Si prega di verificare le modalità di accesso." Ho testato anche su altri portali che hanno già integrato SPID e il problema è sempre presente.

Ne approfitto per chiedere una cosa relativa ai file di log. Noi abbiamo il docker in una Web App di Azure e non riusciamo in FTP a recuperare i file di log perché ci viene dato errore. Può essere che ci sia un lock dei file da parte del docker? Oppure è Azure a creare questo lock?

Grazie, Fabio Scubla

psmiraglia commented 5 years ago

Al momento abbiamo aggiornato il certificato presente nella versione che avevamo, in quanto la major release non è retro compatibile, e ora funziona correttamente.

Bene. Suggerisco di pianificare la migrazione verso la serie 1.x. La retro-compatibilita' riguarda solo e solamente il container. Il modo in cui le informazioni vengono passate al backend e' rimasto invariato.

Ho notato che quello attuale scade il prossimo anno, quindi presumo che sarà da aggiornare ogni anno, è corretto? In modo tale da organizzare l'attività e non creare un disservizio.

Su questo purtroppo non so rispondervi. Potreste mandare un mail a spid.tech@agid.gov.it e chiedere delucidazioni a riguardo.

Vi segnalo che l'unico IdP che dà problema è quello di TIM che riporta il seguente errore: "Si è verificato un errore imprevisto. Pagina non trovata. Si prega di verificare le modalità di accesso." Ho testato anche su altri portali che hanno già integrato SPID e il problema è sempre presente.

Ok. Grazie della segnalazione.

Ne approfitto per chiedere una cosa relativa ai file di log. Noi abbiamo il docker in una Web App di Azure e non riusciamo in FTP a recuperare i file di log perché ci viene dato errore. Può essere che ci sia un lock dei file da parte del docker? Oppure è Azure a creare questo lock?

La gestione dei log e' volontariamente out of the scope visto che il deployment del container puo' variare da scenario a scenario. Una cosa che mi sento di suggerire e' quella di gestire i log utilizzando un approccio "sidecar".