Различия между инициированными SP SSO и инициированными IDP SSO

Может кто-нибудь объяснить мне, какие основные отличия между инициированными SPO SSO и IDP, инициированными SSO, включая, что было бы лучшим решением для реализации единого знака в соединении с федерацией ADFS + OpenAM?

Ответ 1

В IDO Init SSO (Unsolicited Web SSO) процесс федерации инициируется IDP, отправляющим незапрашиваемый ответ SAML на SP. В SP-Init SP генерирует AuthnRequest, который отправляется IDP в качестве первого шага в процессе федерации, и IDP затем отвечает SAML-ответом. Поддержка IMHO ADFSv2 для SAML2.0 Web SSO SP-Init сильнее, чем поддержка IDP-Init: интеграция с продуктами сторонних производителей Fed (в основном, поддержка поддержки RelayState), поэтому, если у вас есть выбор, вы захотите использовать SP- Init, так как это облегчит жизнь с помощью ADFSv2.

Вот несколько простых описаний единого входа из руководства по началу работы с PingFederate 8.0, которое вы можете выполнить, что также может помочь - https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html

Ответ 2

IDP Инициированный SSO

Из документации PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html

В этом случае пользователь входит в IdP и пытается получить доступ к ресурсу на удаленном сервере SP. Утверждение SAML переносится в SP через HTTP POST.

Шаги обработки:

  • Пользователь выполнил вход в IdP.
  • Пользователь запрашивает доступ к защищенному ресурсу SP. Пользователь не зашел на сайт SP.
  • При желании IdP извлекает атрибуты из хранилища пользовательских данных.
  • Служба единого входа IdPs возвращает HTML-форму браузеру с ответом SAML, содержащим утверждение аутентификации и любые дополнительные атрибуты. Браузер автоматически отправляет HTML-форму обратно в SP.

SP Инициированный SSO

Из документации PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST

В этом случае пользователь пытается получить доступ к защищенному ресурсу непосредственно на веб-сайте SP без входа в систему. Пользователь не имеет учетной записи на сайте SP, но имеет федеративную учетную запись, управляемую сторонним IdP. SP отправляет запрос аутентификации в IdP. И запрос, и возвращенное утверждение SAML отправляются через браузер пользователей через HTTP POST.

Шаги обработки:

  • Пользователь запрашивает доступ к защищенному ресурсу SP. Запрос перенаправляется на сервер федерации для проверки подлинности.
  • Сервер федерации отправляет HTML-форму обратно в браузер с запросом SAML для аутентификации из IdP. Форма HTML автоматически отправляется в службу единого входа IdPs.
  • Если пользователь еще не вошел в систему на IdP-сайте или требуется повторная аутентификация, IdP запрашивает учетные данные (например, ID и пароль) и пользователь регистрируется.
  • Дополнительная информация о пользователе может быть получена из пользовательского хранилища данных для включения в ответ SAML. (Эти атрибуты предопределены как часть соглашения федерации между IdP и SP)

  • Служба единого входа IdPs возвращает HTML-форму браузеру с ответом SAML, содержащим утверждение аутентификации и любые дополнительные атрибуты. Браузер автоматически отправляет HTML-форму обратно в SP. ПРИМЕЧАНИЕ. Спецификации SAML требуют, чтобы ответы POST подписывались цифрой.

  • (Не показано) Если подпись и утверждение действительны, SP устанавливает сеанс для пользователя и перенаправляет браузер на целевой ресурс.

Ответ 3

SP Инициированный SSO

SP: "Эй, ты знаешь Сала?"

IdP: "Я?... О, это правильно! Да, я знаю Саль"

SP: "О, круто, я впущу ее".

IdP Инициированный SSO

IdP: "Привет, Сэл говорит, что знаешь ее"

SP: "Я знаю?.. О, да, я дам ее."