Пользовательский сайт входа Spring Security с файлом cookie стороннего сеанса

Я создаю веб-приложение Spring Boot, которое будет действовать как сайт входа для моих пользователей. За кулисами через REST API он использует OpenAM для проверки учетных данных и создания токена сеанса. Я ожидаю, что токен будет использоваться для управления сеансом для этого сайта входа и всех других сайтов, которые мы предлагаем нашим пользователям (единый вход).

Я бы хотел, чтобы приложение SpringBoot не имело гражданства. Это значительно упрощает развертывание. Хотя сайт должен быть без состояния, очевидно, что мы по-прежнему сохраняем состояние сеанса в OpenAM.

Я изо всех сил пытаюсь настроить Spring Security, чтобы файл cookie представлял действительный сеанс, который Spring Security распознает. Когда я делаю приложение без состояния, оно вызывает всевозможные проблемы с защитой CSRF, потому что оно думает, что мы повторно аутентифицируемся с каждым запросом, который имеет токен сеанса OpenAM в файле cookie, и создает новые заголовки CSRF (для защиты от сеанса фиксация).

Я использую PreAuthenticationToken для своего типа аутентификации. Должен ли я использовать RembemberMeAuthenticationToken? Нужно ли мне вводить новую SessionAuthenticationStrategy? В идеале, только фактический POST входа в систему заставляет Spring Security думать, что новый сеанс был создан. Для всех последующих запросов с файлом cookie сеанса он должен просто пропускать его, как если бы он был аутентифицирован. (Я буду проверять токен с помощью OpenAM при каждом запросе)

Мысли? Андрей


spring-boot spring-security session cookies openam
person anschoewe    schedule 03.11.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я создал гибридный сайт, который использует как токен сеанса ForgeRock, так и HttpSession Spring Security по умолчанию. Чтобы обеспечить защиту от CSRF и перехвата сеанса, очень сложно создать приложение, полностью не связанное с сеансом.

Итак, мое приложение использует сеанс Spring для обеспечения проекции CSRF и перехвата сеанса, а также для работы в качестве кеша. Сеанс Spring длится 30 секунд, в течение которых все запросы используют сохраненную основную информацию, и нет необходимости запрашивать ForgeRock для ее проверки. Через 30 секунд сеанс Spring истекает и повторно проверяет сеанс ForgeRock и получает обновленную основную информацию от OpenAM.

Я реализовал несколько хуков в приложении Spring Security, чтобы включить эту функцию. Я использовал Spring Boot, Spring Security и способ конфигурации Java, чтобы связать все это вместе.

  • Я заменил фильтр AbstractPreAuthenticatedProcessingFilter своим собственным фильтром OpenAmCookieAuthentication. В методе doFilter() он проверяет продолжительность сеанса HttpSession, если он существует. Если дольше, чем «x» секунд, сеанс становится недействительным. Это заставляет будущие фильтры повторно проверять файл cookie OpenAM и получать информацию о принципале OpenAM.
  • I replaced the UsernamePasswordAuthenticationFilter filter with my own filter. To be clear, I didn't implement my own filter here, I just configured an UsernamePasswordAuthenticationFilter instance. I set my own custom success and failure handlers
    • I created my own success handler that sets the OpenAM session cookie upon successful authentication with OpenAM. It extended SavedRequestAwareAuthenticationSuccessHandler
    • Я создал свой собственный обработчик ошибок для обработки неудачных входов в систему, который очищает файлы cookie. Он расширил ExceptionMappingAuthenticationFailureHandler
  • Overrode the authenticationManagerBean(). It still utilizes the ProviderManager class, but I pass in my own list of authentication providers
    • Create a UserDetailsService that implements the AuthenticationUserDetailsService<PreAuthenticatedAuthenticationToken> interface. It is used when there is an OpenAM session token that needs to be validated (after Spring session expires after 30 seconds)
    • Создайте поставщика аутентификации, реализующего интерфейс AuthenticationProvider. Это используется во время стандартных процессов входа в систему для проверки учетных данных пользователя с помощью OpenAM.

Наконец, поскольку я не мог сделать приложение полностью апатридным, я реализовал простую репликацию сеанса с помощью встроенного экземпляра Tomcat. Эта реализация была вдохновлена ​​этим сообщением: введите здесь описание ссылки

person anschoewe    schedule 14.11.2016