Buongiorno a tutti, circa 11 mesi fa abbiamo ottenuto il Trust Mark per un membro della federazione CIE dalla Trust Anchor.
In previsione della scadenza dello stesso, è prevista una procedura di rinnovo?
Qualcuno di Voi ha già rinnovato il Trust Mark? in che modo?
grazie
Non vorrei dire una inesattezza, ma credo che tramite l’endpoint “trust mark status” puoi verificare se è ancora valido e tramite quello “fetch” puoi prelevare il nuovo.
Naturalmente devi interrogare chi emette il TM impostando il subject con il membro in questione.
Grazie per la risposta, confermo che quanto suggerito è corretto.
Il mio dubbio però riguarda il fatto che, se facciamo questa verifica quando il Trust Mark è già scaduto, rischiamo di creare un disservizio finché non viene rinnovato. Per questo motivo mi chiedevo se fosse possibile ottenere un nuovo Trust Mark prima della scadenza, in modo da “aggiungerlo” a quelli già presenti e garantire così la continuità del servizio.
Inoltre, provando la funzione da te suggerita, ottengo il Trust Mark attualmente in uso, rilasciato 11 mesi fa.
Grazie ancora per il supporto!
Adesso non ricordo se i TM scadono sempre alla mezzanotte (e quindi schedulare qualcosa in notturna), ma eventualmente fai un job schedulato ogni ora per ridurre il rischio o un check ogniqualvolta interroghi l’entity configuration
confermo che il rinnovo del Trust Mark avviene esattamente nel secondo successivo alla sua scadenza e viene automaticamente esteso per un altro anno.
Ad esempio, per evitare eventuali problemi, è necessario implementare un sistema che, nel minuto pre e post scadenza, recuperi il nuovo TM e lo inserisca nella configurazione.
Questo approccio consente di evitare il rischio di dover gestire un rinnovo manuale, che potrebbe verificarsi anche in giorni non lavorativi come sabato o domenica.
Questa discussione mi interessa molto … non ho capito neanche io come funziona bene questa cosa (magari mi sono perso io il passaggio relativo nella documentazione).
Per quello che ho capito fin ora i trust mark presentano un exp con data e ora, quindi potrebbero scadere nell’istante specifico in cui viene superata quella data e ora.
Inoltre non capisco in che momento l’endpoint di fetch vada a rilasciare il nuovo trustmark.
La questione è abbastanza critica perché se devo gestire la cosa in modo rapido con il rischio che il mio trust mark scada in un momento di piena attività devo registrarmi da qualche parte le scadenze e far partire la richiesta del nuovo trust mark il “secondo dopo”: con il rischio che l’endpoint di fetch non mi restituisca il trustmark “nuovo”. Se viene confermato che ci sono dei margini entro i quali o fetch inizia a rilasciare un nuovo trust mark o i trust mark vengono invalidati a partire dal giorno dopo il giorno contenuto dentro exp: allora è possibile gestire il rinnovo con sistemi asincroni che vanno a fare l’operazione in momenti di basso carico.
Non si può avere un chiarimento ufficiale sul funzionalmento di questo meccanismo? O qualche anima pia che ci linka il passaggio della documentazione che tratta questa cosa 
Per quanto ho visto dentro la libreria spid-cie-oidc-aspnetcore la questione non viene gestita per niente (sia lato trust_mark_status, sia lato fetch, sia lato rinnovo).
PS. l’ultimo passaggio non voleva essere una critica alla libreria in questione ma una semplice constatazione. Se in quella libreria trovavo una minima traccia di gestione della situazione potevo assumere che anche il TA principale si comportava nello stesso modo.
Oggi pensavo ancora a questa cosa e credo che la soluzione migliore sia che ci cancelliamo il trust mark quando vogliamo noi e poi contattiamo l’endpoint di fetch del TA che dovrebbe restituirci un nuovo trust mark con la scadenza aggiornata … Processo da testare ma dovrebbe funzionare così …
Ho approfondito la questione e, dalla documentazione, sembra possibile ottenere un Trust Mark prima della sua scadenza, vedi OpenID Federation 1.0 - draft 41.
Questo permetterebbe di aggiungerlo alla lista dei Trust Mark ed evitare così il disservizio.
Dopo varie considerazioni, ho contattato l’IPZS per verificare se questa soluzione sia praticabile, in modo da evitare che ogni Ente debba trovare una soluzione autonoma a questo problema.
Sono in attesa di una loro risposta.
Grazie dell’aggiornamento @Gian_Paolo_Rossi,
potrei sbagliarmi ma ho verificato le EC pubblicate per il TA di pre produzione e produzione e non vedo un endpoint come quello descritto nel draft che citavi. Io spero che esista o che la mia ipotesi precedente sia valida 
.
Speriamo che IPZS ci dia delucidazioni a riguardo.
devo rettificare questa cosa in quanto rimuovere tutti i trust mark dal proprio EC non consente di ottenere un nuovo trust mark con una scadenza aggiornata.
devi fare un fetch per ottenerli e poi inserirli nell’EC come ti scrissi tempo fa
Grazie @Andrea_Iannone , questa cosa è valida per il recupero del primo trust mark ma per il rinnovo pare che bisogna contattare il fetch endpoint finchè questo non ti restituisce quello nuovo … il problema è che sarebbe carino capire quando fetch inizia a restituire il nuovo trust mark con la nuova scadenza.
Riflettendo, il fatto che i trust mark vengano esposti tramite un array, consente di avere più trust mark esposti contemporaneamente. Anche in questa circostanza bisognerebbe capire se chi trusta valuta tutti i trust mark esposti.
Non so se i miei dubbi dipendano dal fatto che conosco poco OIDC, mi sono perso della documentazione o se effettivamente queste cose non siano state chiarite. Vengo da un esperienza con librerie SAML dove determinati dubbi non esistono, le procedure sono tutte relativamente chiare e possono portare a dei down del servizio.
Io posso chiamare tutti i giorni, per un centinaio di enti, l’enpoint di fetch in attesa che mi restituisca un trust mark di rinnovo ma non mi pare un approccio sensato… sopratutto se iniziamo tutti a fare così per un circa 10000 PA presenti sul territorio e magari qualche privato.
Oltre a questo, non è molto chiaro anche la gestione del JWKS che viene inserito in fase di registrazione della componente tecnica: quando il certificato di federazione scade cosa succede? Qual’e la procedura? Ho aperto una discussione sulla questione (Aggiornamento "Chiave pubblica di federazione") per capire cosa succede perché sia questa procedura di rinnovo, che quella per il JWKS, si prestano a dei grossi rischi di down del servizio e non le trovo molto chiare.
Rispetto a SAML, credo che in questa circostanza, si possano evitare dei down del servizio e magari gestire i rinnovi in modo automatico.
Scusate lo sfogo.
Ma non ti basterebbe contattare il fetch nel momento in cui il trust mark lo controlli e ti risulta scaduto?
Noi quando l’EC viene contattato (sia del SA che dell’RP) effettuiamo sempre questo controllo e nel caso il TM sia scaduto facciamo la fetch sul TA (o sul SA se si tratta di un RP), recuperiamo il TM e lo salviamo nel DB, così da farlo apparire nell’EC
Si, è ovvio … il mio voleva essere un estremizzazione del concetto … siccome il mio applicativo .NET richiede qualche operazione extra per aggiornare la configurazione dell’EC esposta, avrei preferito un qualcosa che mi consentisse di aggiornare l’elenco dei trust mark in orari di basso carico applicativo: tramite un processo asincrono e non sincrono come il tuo.
Oltretutto, essendo il tuo un processo sincrono, se per qualche motivo qualcosa va storto: l’autenticazione CIE non va più e fai un down del servizio.
Magari, qualcuno che conosce come funzionano le cose, può dare qualche specifica ulteriore e aiutarci a creare un processo migliore.
Io credo che lo scopo di questo thread sia quello di avere altre informazioni sul processo di rinnovo… abbiamo compreso che l’endpoint di fetch è il nostro “migliore amico” ma non abbiamo capito se questo “amico” può fare altro per noi e come può farlo.
Confermo che, alla scadenza del Trust Mark, è possibile ottenere un nuovo Trust Mark valido per un ulteriore anno tramite una richiesta di recupero dati (“fetch”).
Tuttavia, questa procedura comporta un rischio: se il nuovo Trust Mark non viene acquisito tempestivamente, tutte le richieste di autenticazione falliranno, causando un’interruzione del servizio.
La soluzione proposta da @Andrea_Iannone, sebbene efficace per prevenire interruzioni, genererebbe un significativo aumento del traffico HTTP verso la Trust Anchor durante l’intero periodo di validità del Trust Mark.
A mio avviso, è necessario rivedere la soluzione fornita da IPZS. Si suggerisce di sfruttare l’endpoint OpenID Federation 1.0 - draft 42 e di fornire il nuovo Trust Mark almeno un mese prima della scadenza. Inoltre, come suggerito da @PiemP, sarebbe opportuno valutare la possibilità di gestire più Trust Mark contemporaneamente.
Ad oggi, non ho ricevuto alcuna risposta da IPZS in merito a queste problematiche.
La chiamata fetch verso il TA la effettuiamo solo quando il TM ci risulta scaduto (con una verifica interna), non ogni qualvolta ci viene richiesto l’EC.
Eventualmente il TM emesso dal SA verso l’RP è comunque gestito internamente e quindi processato secondo nostre logiche interne, potremmo anche rigenerarlo ogni giorno con un job notturno senza sovraccaricare nulla.