Buonasera,
qualche giorno fa il nostro cliente (ente pubblico) ha chiesto di aggiornare il metadata SpID (causa scadenza del certificato di firma e encryption asserzioni) e, dopo una fase di validazione, il metadata aggiornato è stato reso disponibile per essere propagato verso i vari IdP. La tempistica che ci è stata indicata per la propagazione è di circa tre giorni (oggi è il quinto giorno).
Si sta però verificando un comportamento un po’ strano nell’accesso mediante PosteID. Di tanto in tanto è regolarmente mostrata la pagina per l’inserimento delle credenziali col QRCode e l’accesso avviene correttamente, ma più di frequente il sito di poste (i.e. hxxps://posteid.poste.it/jod-fs/ssoserviceredirect?SAMLRequest=YYYYYYYYYYYYYY) mostra il seguente errore:
Tale errore era mostrato anche nel periodo di transitorio in cui si attendeva la propagazione del nuovo metadata per cui, inizialmente, abbiamo pensato di dover solo attendere la propagazione completa. Il particolare curioso è che se si prova ad aggiornare la pagina una o due volte (col classico F5 sulla tastiera) - riproponendo dunque la medesima richiesta SAML - la pagina di login appare correttamente. Abbiamo provato, come tentativo poco convincente, anche a cancellare i cookie ma l’operazione non ha sortito l’effetto sperato.
Abbiamo azzardato l’ipotesi che il metadata non sia stato ancora recepito da tutti i nodi SpID di PosteID (perdonatemi se scrivo castronerie, non conosco l’architettura) e dunque, la richiesta va a buon fine solo quando giunge al nodo col metadata aggiornato. L’ipotesi nasce anche dall’osservazione che altri due provider pare debbano ancora recepire il metadata aggiornato (continuano a segnalare errore di firma). E’ un’ipotesi che può ritenersi corretta? Come si potrebbe verificarla o smentirla?
Potrebbe essere [anche] un problema di skew di orario? Ma non dovrebbe verificarsi sempre e/o anche con gli altri provider? Con gli altri provider attualmente “funzionanti” non sperimentiamo problematiche del genere (accettazione altalenante delle SAMLRequest).
Qualcuno ha già avuto a che fare con qualcosa del genere e/o ha idea di che cosa potrebbe causare tale problematica?
E’ possibile, in qualche modo, richiedere supporto tecnico a PosteID per una specifica SAMLRequest (fornendo riferimento temporale)? L’obiettivo è quello di capire quale possa essere il motivo tecnico/reale dell’errore visualizzato … e trovare un modo per risolverlo/correggerlo.
La cosa migliore che ti posso suggerire è quella di installare come estensione del browser che usi un SAML Tracer
Attraverso questo strumento, tracciate le AuthnRequest che generate (verificando che sia tutto corretto) e soprattutto le Response che ricevete dall’IdP in questione, confrontando l’Error Code con le indicazioni della Tabella Anomalia SPID.
In merito alle tue ipotesi:
Se non parte l’AuthnRequest o non ricevete Response, probabilmente è un problema di caching del browser.
Se l’Error Code è 7 o 10, potrebbe essere un problema di propagazione del metadata all’interno dell’infrastruttura dell’IDP.
Se l’Error Code è 13, potrebbe essere un problema di clock skew (anche se reputo questo scenario poco probabile).
Abbiamo verificato con un SAML Tracer e le AuthnRequest sembrano corrette. D’altro canto a volte non si sperimenta il problema (la richiesta viene accettata direttamente) e, quando si esegue un aggiornamento della pagina con un F5, la SAMLRequest sottomessa è la medesima. Inoltre con gli altri provider non sperimentiamo questo problema.
La pagina di errore ci è mostrata subito dopo aver avviato il processo di login via SpID, richiamando la location del SessionInitiator (utilizziamo una soluzione basata su Shibboleth): la navigazione si conclude alla pagina di errore. Anche provando a cancellare cache di navigazione la problematica continua a verificarsi, purtroppo.
Proviamo ad aumentare il livello di log e a spulciarli per capire se troviamo delle indicazioni.
Nel frattempo ulteriori suggerimenti sono bene accetti.
Per quanto ho visto personalmente non ci arriva nessuna Response quando si verifica quell’anomalia. Però appena posso faccio qualche ulteriore controllo per vedere se mi è sfuggito qualcosa.
Solo per indicarlo esplicitamente. Col SAML Tracer non viene tracciata nessuna Response: non c’è attività di navigazione da quella pagina. Il flusso termina lì senza nessuna redirect o simili.
Le ipotesi su nodi dell’IdP Poste non aggiornati penso siano fondate. Anche a noi in passato è successo che i metadati non fossero propagati ovunque o che ci fossero altri problemi intermittenti con i loro sistemi.
Ciao Martino,
Noi abbiamo stipulato la convenzione come fornitori di servizi privati, non abbiamo alcun problema don gli altri SP, ma con poste non riusciamo ad invocare correttamente il servizio. la SAML Response contiene errore codice 16. Scrivevi che dopo aver contattato poste il problema lo avevano risolto… ma la domanda è come si contatta il supporto di poste spid?
Sono stato rimbalzato dopo ore al tel dal numero 069777… al 800 160 etc… ma mi hanno detto che il servizio risponde solo ai privati…
L’Errore 16 evidenzia un problema all’interno della AuthnRequest, ossia nell’indicazione dell’AssertionConsumerService a cui l’IdP deve invia la Response.
Con un SAML Tracer dovreste ispezionare la AuthnRequest generata e confrontarla con le regole tecnciche ed i dati presenti nel metadata che avete comunicato ad AgID
Sembra tutto corretto, tra l’altro, è l’unico provider a dare problemi… Vorrei provare a contattare poste, ma non ci sono ancora riuscito ad uscire dal tunnel degli help desk…
Esiste un canale diretto che voi sappiate?
Grazie.
Ciao Carlo,
scusami per il ritardo nella risposta.
Io feci un po’ il furbo e chiamai l’800 160 da sottoscrittore SpID di poste (ho spid con poste) , segnalando loro che non riuscivo ad accedere a quello specifico sito (ma solo col loro spid, mentre con quello di altri provider ci riuscivo). Dopo un po’ di azione di persuasione (mi ripetevano di contattare l’autore del sito), convinsi l’operatrice a far aprire un ticket ai tecnici. Dovemmo sentirci tre volte prima che il “problema” fosse completamente risolto
