Может ли кто-нибудь объяснить мне, в чем заключаются основные различия между SSO, инициированным SP, и SSO, инициированным IDP , включая то, что было бы лучшим решением для реализации единого входа в сочетании с ADFS + OpenAM Federation?
Может ли кто-нибудь объяснить мне, в чем заключаются основные различия между SSO, инициированным SP, и SSO, инициированным IDP , включая то, что было бы лучшим решением для реализации единого входа в сочетании с ADFS + OpenAM Federation?
Ответы:
В IDP 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 re: интеграция со сторонними продуктами Fed (в основном вращается вокруг поддержки RelayState), поэтому, если у вас есть выбор, вы захотите использовать SP- Init, поскольку это, вероятно, облегчит жизнь с ADFSv2.
Вот несколько простых описаний системы единого входа из Руководства по началу работы с PingFederate 8.0, которые вы можете просмотреть и которые тоже могут помочь - https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html
SSO, инициированный IDP
Из документации PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html
В этом сценарии пользователь входит в систему IdP и пытается получить доступ к ресурсу на удаленном сервере SP. Утверждение SAML передается SP через HTTP POST.
Этапы обработки:
SSO, инициированный SP
Из документации PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST
В этом сценарии пользователь пытается получить доступ к защищенному ресурсу непосредственно на веб-сайте SP без входа в систему. У пользователя нет учетной записи на сайте SP, но есть федеративная учетная запись, управляемая сторонним IdP. SP отправляет запрос аутентификации IdP. И запрос, и возвращенное утверждение SAML отправляются через браузер пользователя через HTTP POST.
Этапы обработки:
Дополнительная информация о пользователе может быть получена из хранилища пользовательских данных для включения в ответ SAML. (Эти атрибуты предопределены как часть федеративного соглашения между IdP и SP)
Служба SSO IdP возвращает браузеру HTML-форму с ответом SAML, содержащим утверждение аутентификации и любые дополнительные атрибуты. Браузер автоматически отправляет HTML-форму обратно в SP. ПРИМЕЧАНИЕ. Согласно спецификациям SAML, ответы POST должны иметь цифровую подпись.
(Не показано). Если подпись и утверждение действительны, SP устанавливает сеанс для пользователя и перенаправляет браузер на целевой ресурс.
Билл пользователю: «Привет, Джимми, покажи мне этот отчет».
Джимми ИП: «Эй, я еще не уверен, кто вы. У нас есть процедура, поэтому сначала вы должны проверить себя у Боба, IdP. Я ему доверяю».
Боб, IdP: «Я вижу, что Джимми послал вас сюда. Пожалуйста, дайте мне свои учетные данные».
Билл пользователю: «Привет, я Билл. Вот мои учетные данные».
Боб, IdP: «Привет, Билл. Похоже, ты проверял».
Боб, IdP: «Привет, Джимми. Этот парень, Билл, проверяет, и вот дополнительная информация о нем. Делай здесь, что хочешь».
Джимми SP: «Хорошо, круто. Похоже, Билл тоже в нашем списке известных гостей. Я впущу Билла».
Билл, пользователь: «Привет, Боб. Я хочу пойти к Джимми. Там строгая охрана».
Боб, IdP: «Привет, Джимми. Я доверяю Биллу. Он проверяет, и вот дополнительная информация о нем. Отсюда ты делаешь все, что хочешь».
Джимми SP: «Хорошо, круто. Похоже, Билл тоже в нашем списке известных гостей. Я впущу Билла».
Я расскажу здесь более подробно, но все же сохраню простоту: https://jorgecolonconsulting.com/saml-sso-in-simple-terms/ .