Несколько приложений, одинаковые сеансы и роли для обновления

Question

У нас есть сценарий, в котором у нас есть серия приложений, в которых используется Spring-session (w/Redis), где пользователь может несколько раз регистрироваться для доступа к различным приложениям.

Если администратор исправляет пользователя для добавления новой роли (например, доступа к новому приложению) (GrantedAuthority), нам нужно, чтобы это отражалось во всех активных сеансах пользователей.

Проблема заключается в том, что, по моему мнению, SecurityContextHolder использует хранилище ThreadLocal для SecurityContext (которое, в свою очередь, содержит GrantedAuthorities).

Я попытался взаимодействовать с репозиторием сеансов и использовать его для обновления информации о сеансе, но из-за вышеупомянутого хранилища TL он не находит отражение в приложениях.

Существует ли общий шаблон/стратегия для распространения обновлений роли информации таким образом?

Спасибо.

Answer 1

Простейшим (и предпочтительным решением IMO) было бы заставить ваших пользователей повторно аутентифицироваться и, следовательно, создать новый Authentication, который затем будет содержать новую коллекцию GrantedAuthority. Вы можете использовать Spring Session FindByIndexNameSessionRepository, чтобы получить все сеансы для данного пользователя, а затем удалить их. Это приведет к генерации SessionDeletedEvent, который будет распространяться на все ваши приложения (поскольку они имеют один и тот же магазин сеансов Redis).

Если вы должны сохранять активные сеансы, все сложнее. Вы можете использовать FindByIndexNameSessionRepository для получения всех сеансов для данного пользователя, но затем вам нужно извлечь SecurityContext с каждого сеанса и обновить его Authentication новыми полномочиями и убедиться, что это сделано для всех приложений, которые совместно используют хранилище сеансов. Для этого вам нужно отключить eraseCredentialsAfterAuthentication на вашем ProviderManager, чтобы вы могли повторно создать Authentication с новыми полномочиями (вам нужны учетные данные от оригинала Authentication). Чтобы обеспечить обновление SecurityContext во всех ваших приложениях, вам необходимо использовать какой-то механизм публикации-подписки, чтобы инициировать выполнение этого кода.

Как вы видите, первое решение намного проще и безопаснее (поскольку вам не нужно отключать eraseCredentialsAfterAuthentication). Также стоит отметить, что второе решение было бы проще, если Spring Session поддерживал HttpSessionAttributeListener (см. this ticket), поскольку это будет охватывать часть механизма публикации-подписания.