Spring Security Wygaśnięcie potwierdzenia SAML z wygaśnięciem sesji aplikacji

Question

Dezorientuję się z wygaśnięciem asercji SAML w związku z wygaśnięciem sesji aplikacji.

W prostych słowach, gdy mamy wdrożoną aplikację w kontenerze, tworzona jest sesja. Ta sesja wygaśnięcie może być kontrolowany przy użyciu poniższego wpisu w web.xml

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

Idąc dalej, kiedy mam Wiosna Security z rozszerzeniem SAML, oczywiście dotyczy to samo pojęcie sesji. (Wdrażam aplikację w WildFly 8.2, jeśli to ma znaczenie)

Co więcej, po wygaśnięciu sesji aplikacji zachowanie się wylogowanego wydaje się być równoważne z koncepcją lokalnego wylogowania.

Jak dotąd tak dobrze. Teraz powiedzmy, że asercja SAML jest dobra przez 2 godziny, a użytkownik aktywnie pracuje przez 2 godziny. Co powinno stać się z późniejszym wnioskiem? Czy powinien ponownie zalogować się do IDP? Ale czy nie byłoby to niewygodne dla użytkownika? Jeśli aplikacja przekierowuje do IDP w celu ponownego zalogowania po 2 godzinach wygaśnięcia potwierdzenia, w jaki sposób należy przetwarzać żądania AJAX?

To w nawiązaniu do the question here

Answer 1

Wiosna SAML wystawia ExpiringUsernameAuthenticationToken dla uwierzytelnionych użytkowników. Token rozpoczyna zwracanie wartości false w metodzie isAuthenticated(), gdy asercja SAML używana do uwierzytelnienia użytkownika osiągnie jego czas sessionNotOnOrAfter.

Takie zachowanie może być wyłączone przez przesłanianie SAMLAuthenticationProvider i zmianę sposobu getExpirationDate(credential), która zwraca czas po wygaśnięciu twierdzenia lub null w przypadku, gdy nie robi. Aplikacja będzie wtedy w pełni polegać na wygaśnięciu sesji skonfigurowanym w kontenerze.

Po wygaśnięciu ExpiringUsernameAuthenticationToken program Spring Security przekaże bieżący token do AuthenticationManager (skonfigurowany w pliku securityContext.xml pod numerem <security:authentication-manager>).

Możesz wpłynąć na to, co dzieje się dalej, dodając własny AuthenticationProvider w stanie obsłużyć ExpiringUsernameAuthenticationToken. W przeciwnym razie system zawiedzie z ProviderNotFoundException lub innym AuthenticationException, takim jak BadCredentialsException (w przypadku, gdy używasz uwierzytelniania nazwy użytkownika/hasła w tym samym czasie).

Wyjątek jest następnie obsługiwany przez ExceptionTranslationFilter, który rozpoczyna nowy proces uwierzytelniania, wywołując skonfigurowane uwierzytelnienie EntryPoint - np. SAMLEntryPoint, która uruchamia uwierzytelnianie z domyślnym IDP lub wyświetla stronę wyboru IDP. Zasadniczo proces ten będzie również przeprowadzał wylogowanie lokalne.

System działa domyślnie tak samo dla wszystkich połączeń HTTP - AJAX lub nie. Możesz zdefiniować inne zachowanie, dzieląc interfejs API i zwykłe adresy URL na oddzielne elementy <security:http> i dla każdego z nich użyj innego EntryPoints (interfejs AuthenticationEntryPoint). Na przykład Http403ForbiddenEntryPoint może być odpowiedni dla twoich wywołań AJAX.