Весна безопасности пользовательских войти сайт с 3-й партии сессии Cookie

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

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

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

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

Мысли?
Эндрю

1 ответ

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

    Таким образом, мое приложение использует весеннюю сессию, чтобы обеспечить CSRF и проекцию захвата сессии, а также действовать в качестве кэша. Весенний сеанс длится 30 секунд, в течение которых все запросы используют сохраненную основную информацию и не требуют запроса ForgeRock для ее проверки. По истечении 30 секунд весенний сеанс завершается и повторно проверяет сеанс ForgeRock и получает обновленную основную информацию от OpenAM.

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

    • Я заменил AbstractPreAuthenticatedProcessingFilterфильтр на мой собственный OpenAmCookieAuthentication фильтр. В методе doFilter () проверяется длительность HttpSession, если он существует. Если больше, чем » X » секунд, это делает сеанс недействительным. Это заставляет будущие фильтры повторно проверить файл cookie OpenAM и получить основную информацию OpenAM.
    • Я заменил UsernamePasswordAuthenticationFilterфильтр на свой собственный. Чтобы быть ясным, я не реализовал свой собственный фильтр здесь, я просто настроил UsernamePasswordAuthenticationFilterэкземпляр. Я устанавливаю свои собственные обработчики успеха и неудачи
      • Я создал свой собственный обработчик успеха, который устанавливает файл cookie сеанса OpenAM при успешной аутентификации с OpenAM. Он продлен SavedRequestAwareAuthenticationSuccessHandler
      • Я создал свой собственный обработчик сбоя для обработки неудачных Логинов, который очищает файлы cookie. Он продлен ExceptionMappingAuthenticationFailureHandler
    • Проехал authenticationManagerBean(). Он по-прежнему использует класс ProviderManager, но я передаю свой собственный список поставщиков проверки подлинности
      • СоздайтеUserDetailsService, который реализует AuthenticationUserDetailsService<PreAuthenticatedAuthenticationToken>интерфейс. Он используется, когда есть токен сеанса OpenAM, который должен быть проверен (после окончания весеннего сеанса через 30 секунд)
      • Создайте поставщика проверки подлинности, реализующего AuthenticationProviderинтерфейс. Это используется во время стандартных процессов входа в систему для проверки учетных данных Пользователя с OpenAM.

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