У меня есть микросервис аутентификации в литейном облаке Pivotal, который построен на Spring SAML2. Он интегрирован с PingFederate IDP. Всякий раз, когда эта служба вызывается из веб-приложения, создается JSESSIONID. Для того, чтобы эта служба работала правильно, необходимо включить липкий сеанс. Http-запрос на аутентификацию и ответ должен обрабатываться одним и тем же экземпляром службы в PCF. Однако этого не происходит. Запрос отправляется из одного экземпляра, а ответ возвращается в другой. Поскольку ответ не находит сообщение SAML в текущем сеансе, проверка подлинности не выполняется. Ниже поток -
Браузер -> GoRouter для пользовательского интерфейса -> Служба угловых интерфейсов и обратный прокси-сервер Nginx -> GoRouter для API -> Служба аутентификации -> PingFed
PCF позволяет проводить липкие сессии на основе JSESSIONID. Однако когда веб-приложение пытается получить доступ к службе аутентификации через обратный прокси-сервер Nginx, для одного JSESSIONID создается 2 VCAP_ID . Из-за этого ответ от PingFed не может достичь того же экземпляра службы аутентификации из запроса. Итак, я хотел бы знать, почему PCF создает 2 __VCAP_ID для JSESSIONID, когда запрос поступает через обратный прокси-сервер?
Я пробовал другое хранилище, например Redis Но поскольку Spring sAML2 работает на httpstorage, я не добился успеха. Это все равно что взломать Spring Saml2, чего я не хочу делать.
Я попытался проверить, к какому приложению принадлежат VCAP_ID, перезагрузив приложения. Я узнал, что один VCAP_ID был для экземпляра обратного прокси, а другой - для службы аутентификации. Таким образом, VCAP_ID для обратного прокси-сервера вызывает проблему, и я не уверен, как ее устранить.
Ожидается: PCF должен создать ОДИН VCAP_ID для JSESSIONID для каждого экземпляра.
Факт: PCF создает ДВА VCAP_ID для JSESSIONID на экземпляр