#cloud-foundry
#cloud-foundry
Вопрос:
У меня есть микросервис аутентификации в Pivotal cloud foundry, который построен на Spring SAML2. Он интегрирован с PingFederate IDP. Всякий раз, когда эта служба вызывается из веб-приложения, создается JSESSIONID. Для правильной работы этой службы необходимо включить sticky session. HTTP-запрос на аутентификацию и ответ должны обрабатываться одним и тем же экземпляром службы в PCF. Однако этого не происходит. Запрос отправляется из одного экземпляра, а ответ возвращается в другой экземпляр. Поскольку ответ не находит сообщение SAML в текущем сеансе, проверка подлинности завершается с ошибкой. Ниже приведен поток —
Браузер -> GoRouter для пользовательского интерфейса -> Служба пользовательского интерфейса Angular и обратный прокси-сервер 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 для каждого экземпляра
Комментарии:
1. Здесь есть пара вещей: 1.) «PCF» — это целая куча вещей, поэтому, когда вы утверждаете, что он добавляет заголовки, вам нужно быть намного более конкретным. 2.) Я не вижу на вашей диаграмме маршрутизатора, и это то, что обычно вставляло бы VCAP_ID, можете ли вы дать более точное описание потока запросов? Вам нужно будет перейти ниже и посмотреть, на каком именно этапе потока запросов добавляется дополнительный заголовок. Когда вы сможете определить, какой переход добавляет запрос, тогда можно будет разобраться, почему он туда добавляется.
2. @DanielMikusa, я отредактировал поток, чтобы он был конкретным и включал в себя маршрут. Надеюсь, это поможет. Служба пользовательского интерфейса и служба аутентификации — это разные экземпляры в PCF. Обратный прокси-сервер Nginx является частью экземпляра пользовательского интерфейса. Дополнительный VCAP_ID добавляется, когда трафик поступает через GoRouter for API в службу аутентификации.
3. Ваш Nginx пересылает файлы
JSESSIONIDamp;__VCAP_ID__cookies в службу аутентификации?__VCAP_ID__определенно не будет действительным, потому что это другое приложение, и оно будет иметь идентификаторы экземпляра, иJSESSIONIDбудет действительным только в том случае, если вы делитесь файлами cookie между двумя разными приложениями. Вероятно, вам следует отфильтровывать файлы cookie из вашего внешнего интерфейса в Nginx и переопределять их теми же именами файлов cookie, но со значениями, которые действительны в вашем внутреннем приложении.4. Да. JSESSIONID и VCAP_ID пересылаются в службу аутентификации. Но он выбирает VCAP_ID NGINX вместо VCAP_ID службы авторизации. JSESSIONID создается в службе аутентификации. Но не уверен, почему VCAP_ID создается для Nginx. Nginx используется как обратный прокси-сервер для пересылки всех запросов в серверную службу аутентификации. Здесь я запутался и застрял.
5. Еще одна проблема заключается в том, что, поскольку существует 2 VCAP_ID , я не уверен, какой из них выбрать и установить в заголовке. Теперь, по умолчанию, он выбирает VCAP_ID для Nginx, который мне не нужен.