Scadenza SAML di scadenza Spring Security con Scadenza sessione applicazione

Question

Mi confondo con la scadenza dell'asserzione SAML rispetto alla scadenza della sessione dell'applicazione.

In parole semplici, quando un'applicazione viene distribuita in un contenitore, viene creata una sessione. Questa scadenza sessione può essere controllata con l'iscrizione qui sotto in web.xml

<session-config> 
    <session-timeout>60</session-timeout> 
</session-config> 

Passando, quando ho Primavera di sicurezza con l'estensione SAML, ovviamente, lo stesso concetto si applica sessione. (Sto distribuendo l'applicazione in WildFly 8.2, se ciò è importante)

Inoltre, quando la sessione dell'applicazione scade, il comportamento di disconnessione sembra essere equivalente al concetto di disconnessione locale.

Fin qui tutto bene. Ora diciamo che l'asserzione SAML è valida per 2 ore e l'utente ha lavorato attivamente per 2 ore. Cosa dovrebbe succedere alla richiesta successiva, allora? Dovrebbe riconnettersi all'IDP? Ma non sarebbe un inconveniente per l'utente? Se l'applicazione reindirizza a IDP per accedere nuovamente dopo 2 ore di scadenza dell'asserzione, come devono essere gestite le richieste AJAX?

Questo è in riferimento alla the question here

Answer 1

Primavera SAML emette un ExpiringUsernameAuthenticationToken per gli utenti autenticati. Il token inizia a restituire false nel suo metodo isAuthenticated() una volta che l'Asserzione SAML utilizzata per autenticare l'utente raggiunge il tempo sessionNotOnOrAfter.

Questo comportamento può essere disabilitato sovrascrivendo SAMLAuthenticationProvider e il metodo getExpirationDate(credential), che restituisce il tempo che cambia quando l'Asserzione scade o null nel caso in cui non lo fa mai. L'applicazione si baserà quindi completamente sulla scadenza della sessione configurata nel contenitore.

Una volta scaduto il ExpiringUsernameAuthenticationToken, Spring Security passa il token corrente allo AuthenticationManager (configurato in securityContext.xml in <security:authentication-manager>).

È possibile influire su ciò che accade dopo, aggiungendo il proprio AuthenticationProvider in grado di gestire ExpiringUsernameAuthenticationToken. In caso contrario, il sistema non riesce con ProviderNotFoundException o con altri AuthenticationException come BadCredentialsException (nel caso in cui si stia utilizzando l'autenticazione nome utente/password contemporaneamente).

L'eccezione viene successivamente gestita da ExceptionTranslationFilter, che avvia il nuovo processo di autenticazione richiamando l'autenticazione configurata EntryPoint - ad es. SAMLEntryPoint che avvia l'autenticazione con IDP predefinito o visualizza la pagina di selezione IDP. Il processo eseguirà essenzialmente anche il logout locale, come dici tu.

Il sistema di default si comporta allo stesso modo per tutte le chiamate HTTP - AJAX o no. È possibile definire un comportamento diverso suddividendo l'API e gli URL normali in elementi separati <security:http> e utilizzare diversi EntryPoints (interfaccia AuthenticationEntryPoint) per ciascuno. Ad esempio, Http403ForbiddenEntryPoint potrebbe essere adatto alle tue chiamate AJAX.