IdP-initiated SLO

[simevo]

per testare interattivamente il flusso della LogoutResponse nelle implementazioni di SP, sarebbe utile avere un modo per avviare il single logout presso il gestore dell’identità, ad esempio:

se ho capito bene l'avviso n. 3, in effetti il bottone "Force logout" dovrebbe però dovrebbe essere per gli utenti non per gli SP, in questo modo li sconnette dalla "sessione globale" che può vederli autenticati con diversi SP ..

in ogni caso credo che questo punto sia legato a #105

[alranel]

Sì @simevo, per essere precisi il tasto "Forza logout" dovrebbe essere per sessione.

[alranel]

Un modo per realizzare questa cosa senza #105 potrebbe essere quello di avere il bottone "Forza logout" per SP (come nel tuo mockup qui sopra) e poi chiedere all'utente di inserire a mano il SessionIndex per il quale iniziare il logout.

[mauromol]

@alranel @peppelinux Appurato che a livello di interfaccia non c'è questa possibilità, mi chiedo se per caso ci sia ad oggi un qualche modo (da linea di comando, invocando manualmente un qualche URL dell'IdP di test, ecc.) per avviare una procedura di logout IdP-initiated in modo da poter testare la propria implementazione lato SP. Grazie.

[peppelinux]

Ciao @mauromol
questo implica che un SP debba accettare delle Response non sollecitate.
Considera che alcuni IdP forzano L2 e non detengono alcuna sessione di SSO tale da poter fare richiesta di global logout.

Per fare uan simulazione creau n flusso IdP-initiated logout firmando una request con la chiave privata dell'IdP di test ed inviala (mediante POSTman) al tuo SP.

In questo devi considerare:

• restrizioni same site cookie del browser (se il tuo SP usa un cookie di sessione e questo non risulti essere samesite='none')
• che il cookie di un SP non fosse già scaduto per qualche ragione. Esempio un utente chiude il browser poi lo riapre e va sull'IdP per fare initiated logout. Bene, l'SP non lo consentirebbe più perché ha già distrutto la sessione dell'utente.

insomma, il logout va gestito con molta attenzione

[mauromol]

@peppelinux sì, certo, infatti nell'implementare il mio SP ho aggiunto anche il supporto a Response non sollecitate, ma appunto ad oggi non so bene come testarle. O meglio, mi hai dato giustamente la dritta più "hardcore" (ergo: generarmi la richiesta a mano, firmarla ed inviarla con Postman), vedrò se riesco a fare delle prove, così su due piedi non è proprio immediato.

Sì, sono consapevole del discorso cookie ed in generale sono d'accordo che è forse persino più complesso implementare completamente il logout che non il login. In realtà poi nel mio sistema esiste un SP proxy a cui si appoggiano i servizi finali, i quali, in caso di notifiche di logout IdP-initiated, ricevono una notifica che va a marcare come scaduta (se ancora aperta) la sessione locale dell'utente, il quale dunque alla prima richiesta successiva all'evento verrà "accompagnato alla porta". Questo senza un (potenzialmente luuungo) ping-pong dell'utente attraverso tutti i servizi finali partecipanti alla sessione SPID proxati, che rischierebbe di rompersi in qualunque punto della catena non appena uno dei servizi finali dovesse andare in errore e richiederebbe un'orchestrazione non banale da dirigere.

Sono anche consapevole che una sessione SPID si instaura solo con autenticazione di livello L1 (che, da raccomandazioni AgID, nei casi reali sembrerebbe non essere mai "adeguata"): a tal proposito ti segnalo che anche spid-testenv2 (così come spid-saml-check) soffre del problema che restituisce un SessionIndex anche con livello di autenticazione stabilito >= L2.

Al di là del discorso del livello di autenticazione, comunque, non ho idea di quanti (ed eventualmente quali) Identity Provider implementino la funzionalità di global logout di sessioni L1, sinceramente con le mie credenziali SPID non ho mai provato a farlo. Magari non la implementa nessuno e quindi stiamo parlando solo di un "virtuosismo"...

[peppelinux]

Ciao @mauromol come al solito i tuoi interventi sono ottimi.

Grazie per avermi fatto notare che con estrema probabilità potremmo "rilassare" l'uso di SessionIndex all'interno delle regole tecniche, di fatto questo valore viene creato automaticamente da tutte le librerie SAML2 SSO IdP e di fatto suona come troppo pedante chiedere delle specializzazioni di questo nei casi L2 e L3. @damikael

Di fatto le librerie inviano sempre SessionIndex come riferimento, indipendentemente dallo stato reale della sessione all'interno dell'IdP (che in caso di forceauthn=True, seppur attiva non avrebbe alcun effetto ai fini dell'autenticazione)

Nella maggiorparte dei casi l'identificativo della sessione lato SP è autorevole esclusivamente all'interno del cookie emesso dal SP, questo contiene di fatto l'identificativo della sessione (avulsa dal contesto SAML2). Scott Cantor ha fatto di tutto per creare SAML2 indipendente rispetto alle sessioni interne ai SP e di fatto ai cookie, possiamo affermare che ci è riuscito tuttavia il mondo reale ha continuato sulla sua strada, con gli approcci già ampiamente consolidati all'uso dei cookie.

Samesite cookie e le future (direi imminenti) restrizioni sui cookie di terze parti confermeranno la visione di Cantor purtroppo e sono in opera alcune azioni e workaround:
https://github.com/WICG/WebID

Mi fa piacere sapere che usi un Proxy e non a caso stai affrontando questo problema. Per curiosità ti chiederei ulteriori informazioni sulla tua implementazione e se questa fosse basata su una delle soluzioni già disponibili in github italia.

Del resto devo confessarti che mediante l'uso dei proxy ho sempre forzato L2 e forceAuthn=True, i rispettivi SP detengono la policy di lifetime del cookie e solo se questo scadesse costringerebbe gli SP a chiedere nuovamente una autentica. Questo è dovuto al fatto che le interazioni cross-domain rendono problematica la gestione di un SSO puro (perché determinato da entità efferenti a domini diversi, tale che un bug di regressione presso una entità di terze parti possa rivelarsi un problema di sicurezza presso la tua organizzazione e i tempi per la sua risoluzione non sarebbero certi).

Ad ogni modo se ne volessimo parlare più approfonditamente raggiungici su slack developers italia #spid. Le nostre considerazioni, sintetizzate, verrebbero poi riflesse in queste issue e nei progetti di documentazione e SDK

[mauromol]

Per quanto riguarda l'uso del SessionIndex, a mio parere se SPID non intende supportare il concetto di sessione globale SPID (all'interno della quale l'eventuale login dell'utente su più SP avviene automaticamente senza l'inserimento ripetuto delle proprie credenziali SPID, al netto di ForceAuthn) a livello 2 e 3, allora sarebbe corretto che, come prevedono oggi le specifiche, questo SessionIndex non venisse restituito in quei casi. In questo modo gli SP possono capire qualora una sessione sia stata creata (e quindi sia disponibile l'operazione di Single Logout) oppure no. È pur vero che esiste anche l'attributo SessionNotOnOrAfter che potrebbe essere inteso come "se specificato signifca che c'è la sessione, altrimenti significa che non c'è alcuna sessione", però vedo un po' in contraddizione che sia restituito uno SessionIndex anche laddove non ci sia sessione. Del resto, se il problema nel gestire il SessionIndex è da imputare all'uso che ne viene fatto dalle librerie SAML 2.0, mi sorprende che non possa essere controllato a piacere, essendo lo stesso SessionIndex attributo opzionale nelle specifiche SAML.

Il proxy di cui ti parlavo in realtà l'ho realizzato io, per la società per cui lavoro: sostanzialmente, avendo la necessità di aggiungere il supporto a SPID a numerosi applicativi interni, o mettevamo mano a tutti gli applicativi per supportare SPID/SAML, o seguivamo un approccio di questo tipo, in modo da semplificare all'osso l'API tra applicativi e proxy, e scaricare sul proxy l'onere di implementare tutta la specifica, curare l'elenco degli IdP e tutto il resto. A livello implementativo, trattasi di applicazione Spring Boot che fa uso della libreria java-saml di OneLogin pesantemente modificata (troverai infatti tutta una serie di mie PR aperte nell'ultimo mese circa per estendere la libreria e/o renderla più estensibile per poter supportare alcune storture di SPID), il tutto affiancato da uno strato client da applicare sugli applicativi finali che prevede la configurazione dei componenti di Spring Security necessari al fine di autorizzare l'utente autenticato mediante SPID all'accesso alle risorse protette (con conseguente mappatura dell'utente SPID su quello "locale" all'applicazione). Ho optato per una soluzione "make" perché, dopo aver guardato un po' soluzioni tipo Shibboleth ho ritenuto più facile e veloce realizzare una soluzione ritagliata sulle nostre esigenze piuttosto che imbarcarmi in un lavoro di adattamento che mi è sembrato comunque piuttosto complesso.

[peppelinux]

@mauromol hai puntualmente ragione e condivido tutto quello che hai detto su SessionIndex e le condizioni NotOnAfter, che di fatto costringono i developers a prendere delle decisioni e ad avere un po di polso.

Sulla riscrittura di testenv2 manterrò questa issue in risalto.

Tornando a noi, mi sembra di capire che il fork che tu utilizzi per sopravvivere a tutte le customizzazioni SAML2 sia questo:
https://github.com/mauromol/java-saml/tree/all-changes

e ti vorrei chiedere, anche se credo che sia il caso di parlarne su slack #spid se ti piacerebbe condividere la tua soluzione su github italia. Anche io per sopravvivere sono stato costretto a fare un fork di pysaml2 ... Capisco la condizione.

Dai, sono li che ti aspetto, facciamo due chiacchiere se ti va