Аутентификация и управление сеансом в приложении с распределенной пружиной

Question

Я работаю над переносом однопользовательского весеннего веб-приложения в модульную архитектуру на основе JMS. У этого link есть структура приложения прямо сейчас и моя цель.

Я буду использовать SSO-сервер на основе CAS, который выполняет аутентификацию. Стек технологий будет весенней загрузкой, Apache Camel, ActiveMQ и spring-security/apache-shiro.

См., Например, У меня будет приложение инвентаризации, финансовое приложение и приложение CAS (SSO Server). В некотором месте мне нужно управлять централизованным хранилищем сеансов, которое будет содержать текущий идентификатор пользователя и их настройки.

использования:

1. журналы пользователей в CAS SSO и идет к модулю инвентаризации. Модуль инвентаризации получит текущий идентификатор пользователя и его предпочтения (из центрального хранилища сеансов?) И будет инициирована транзакция продажи.
2. После того, как инвентаризация выполнена, она отправляет JMS-сообщение через Apache Camel в финансовую отчетность для проводки бухгалтерских записей.
3. Финансовое приложение получает текущий идентификатор пользователя и настройки от сеанса и завершает проводку учетной записи.

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

Answer 1

Хорошо, это старый вопрос, который остался без ответа, проверьте Spring Session, это точно what it's designed for.

На сегодняшний день наиболее распространенным хранилищем сеансов является Redis, но он поддерживает и другие магазины, например, я использую Hazelcast.

Кроме того, использование CAS просто влияет на Spring Security, поэтому не имеет значения, что вы используете для аутентификации ваших пользователей, как управлять сеансами.

При аутентификации не забудьте указать еще один уровень аутентификации среди служб (федерация услуг), поэтому не только кто-либо из вашей системы отправляет сообщения вашим службам.