Браузер не пересылает файлы cookie на сервер единого входа при получении файлов cookie через прокси-сервер - PullRequest
0 голосов
/ 22 января 2019

РЕЗЮМЕ

  • При использовании сервера единого входа (протоколы SAML) я могу напрямую направьте браузер на клиент A, а затем на клиент B. Оба запроса успех.
  • Но при входе в клиент A через прокси-сайт браузер запрос для клиента B игнорирует файлы cookie от запроса клиента.
  • Какую магию мне здесь не хватает? Могу ли я успешно использовать мой "прокси" Войти "решение?

Подробнее 1014 *

В моей вселенной у меня есть экземпляр сервера единой регистрации Red Hat (RH-SSO) с использованием протокола SAML. Мой SSO является поставщиком удостоверений (IdP), а у моего партнера есть поставщик услуг SSO (SP).

Я могу успешно использовать этот сценарий, который демонстрирует, что у меня настроены вещи:

  1. Направьте браузер на мой IdP для клиента A.

  2. IdP говорит, что я еще не вошел в систему, и отвечает со страницей входа.

  3. Заполните и отправьте страницу входа.

  4. IdP аутентифицирует мои учетные данные и говорит браузеру перенаправить на SP партнера.

  5. Браузер связывается с SP партнера, используя учетные данные SAMLResponse.

  6. ИП партнера принимает учетные данные и перенаправляет браузер на веб-страницу A.

  7. Направьте браузер на мой IdP для клиента B.

  8. IdP сообщает, что я вошел в систему, и просит браузер перенаправить на SP партнера.

  9. SP партнера принимает учетные данные и перенаправляет браузер на веб-страницу B.

Этот сценарий работает, но требует, чтобы мой пользователь посетил страницу входа. Я хочу, чтобы мой сервер автоматически делал логин для единого входа. Примерно так:

  1. Направьте браузер на мой существующий бизнес-сайт.

  2. Пользователь входит в систему, используя устаревшую систему аутентификации.

  3. Нажмите на ссылку, которая открывает новое окно.

  4. В новом окне существующий бизнес-сайт открывает канал обратной связи с RH-SSO.

  5. В обратном канале попросите клиента A.

  6. IdP отвечает страницей входа.

  7. В обратном канале страница входа заполняется и отправляется. Пользователю не надоедает еще одна страница входа.

  8. В обратном канале IdP аутентифицирует мои учетные данные и сообщает браузеру перенаправить на SP партнера.

  9. Эта возвращенная страница с заголовками и файлами cookie переносится из обратного канала в исходный ответ браузера.

  10. Браузер связывается с SP партнера, используя учетные данные SAMLResponse.

  11. ИП партнера принимает учетные данные и перенаправляет браузер на веб-страницу A.

  12. Направьте браузер на мой IdP для клиента B.

  13. IdP сообщает, что я вошел в систему, и говорит браузеру перенаправить на SP партнера.

  14. SP партнера принимает учетные данные и перенаправляет браузер на веб-страницу B.

Эта система «прокси-входа в систему» ​​отличается от вызова, инициированного IdP, следующим образом:

  • Система "прокси-сервер входа в систему" знает, кто запрашивает переход к клиенту А, и использует эту информацию для входа на сервер SSO через прокси.
  • Система «прокси-сервер входа в систему» ​​связывается с SSO через URL-адрес бизнес-сайт, не использующий URL-адрес SSO IdP.

Я уже реализовал обе системы. Я удостоверился и проверил, что они оба возвращают браузеру идентичный заголовок и информацию cookie.

Вот основной признак моей проблемы: браузер отказывается использовать куки-файлы, возвращаемые из ответа «прокси-сервер». Даже если я отправлю запрос веб-страницы на существующий бизнес-сайт, файлы cookie не используются.

Я уже пробовал различные решения, такие как добавление атрибутов "Domain =" в файлы cookie, редактирование "Path =". Даже cookie-файл балансировщика нагрузки игнорируется браузером в сценарии «клиент B» (доказал это путем отслеживания того, что видит балансировщик нагрузки).

Это мой вопрос:
Как я могу настроить вещи так, чтобы я мог продолжать использовать прокси-сервер для входа в систему с помощью единого входа, и, тем не менее, при использовании вызова «client B» использовать файлы cookie, возвращаемые из проксифицированного вызова «client A»?

ТИА

Jerome.

...