Истечение срока действия подтверждения SAML Spring Security с истечением сеанса приложения

Question

Я запутался в истечении срока действия утверждения SAML и истечении сеанса приложения.

Проще говоря, когда у нас развернуто приложение в контейнере, создается сеанс. Это истечение сеанса можно контролировать с помощью записи ниже в web.xml

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

Двигаясь дальше, когда у меня Spring Security с расширением SAML, очевидно, что применяется та же концепция сеанса. (Я развертываю приложение в WildFly 8.2, если это имеет значение)

Кроме того, когда сеанс приложения истекает, поведение выхода из системы кажется эквивалентным концепции локального выхода из системы.

Все идет нормально. Теперь давайте скажем, что утверждение SAML хорошо в течение 2 часов, а пользователь активно работает в течение 2 часов. Что должно произойти с последующим запросом? Должен ли он повторно войти в систему для IDP? Но разве это не будет неудобно для пользователя? Если приложение перенаправляется в IDP для повторного входа в систему через 2 часа после истечения срока действия подтверждения, как следует обрабатывать запросы AJAX?

Это в связи с вопросом здесь

Answer 1

Spring SAML выдает ExpiringUsernameAuthenticationToken для аутентифицированных пользователей. Токен начинает возвращать false в своем isAuthenticated() метод, как только утверждение SAML, используемое для аутентификации пользователя, достигает его sessionNotOnOrAfter время.

Это поведение можно отключить, переопределив SAMLAuthenticationProvider и изменение метода getExpirationDate(credential), который возвращает время, когда истекает Утверждение, или null на случай, если это никогда не произойдет. Приложение будет полностью полагаться на истечение сеанса, настроенное в контейнере.

Однажды ExpiringUsernameAuthenticationToken истекает, Spring Security передает текущий токен AuthenticationManager (настраивается в securityContext.xml под <security:authentication-manager>).

Вы можете повлиять на то, что происходит дальше, добавив свой собственный AuthenticationProvider в состоянии справиться с ExpiringUsernameAuthenticationToken, В противном случае система выходит из строя с ProviderNotFoundException или какой-то другой AuthenticationException лайк BadCredentialsException (если вы используете аутентификацию по имени пользователя и паролю одновременно).

Исключение впоследствии обрабатывается ExceptionTranslationFilter, которые запускают новый процесс аутентификации, вызывая настроенную аутентификацию EntryPoint - например SAMLEntryPoint который либо запускает аутентификацию с IDP по умолчанию, либо отображает страницу выбора IDP. Процесс, как вы говорите, также будет выполнять локальный выход из системы.

Система по умолчанию ведет себя одинаково для всех HTTP-вызовов - AJAX или нет. Вы можете определить другое поведение, разделив ваш API и обычные URL на отдельные <security:http> элементы и использовать разные EntryPoints (интерфейс AuthenticationEntryPoint) для каждого. Например Http403ForbiddenEntryPoint может подойти для ваших звонков AJAX.