Różnice pomiędzy SP zainicjowany SSO i IDP zainicjowany SSO

Question

Czy ktoś może mi wyjaśnić, jakie są główne różnice między SP zainicjowany SSO i IDP zainicjowany SSO są tym, co byłoby lepszym rozwiązaniem do wdrożenia pojedynczy znak na w połączeniu z ADFS + Federacja OpenAM?

Answer 1

W SSO typu Init IDP (niezapowiedziana Web SSO) proces federacji jest inicjowany przez IDP wysyłającego niezamawianą odpowiedź SAML do SP. W SP-Init SP generuje żądanie AuthnRequest, które jest wysyłane do IDP jako pierwszy krok w procesie Federacji, a IDP odpowiada odpowiedzią SAML. Obsługa IMHO ADFSv2 dla SAML2.0 Web SSO SP-Init jest silniejszy niż obsługa IDP-Init re: integracja z produktami innych producentów Fed (głównie z obsługą RelayState), więc jeśli masz wybór, będziesz chciał użyć SP-a Init, ponieważ prawdopodobnie ułatwi życie z ADFSv2.

Oto kilka prostych opisów SSO z PingFederate 8,0 Getting Started Guide, które można kłuć przez które mogą pomóc także - https://documentation.pingidentity.com/pingfederate/pf80/index.shtml#gettingStartedGuide/task/idpInitiatedSsoPOST.html

Answer 2

IDP Zainicjowany SSO

Z dokumentacji PingFederate: - https://docs.pingidentity.com/bundle/pf_sm_supportedStandards_pf82/page/task/idpInitiatedSsoPOST.html

W tym scenariuszu użytkownik jest zalogowany do dostawcy tożsamości i próbuje uzyskać dostęp do zasobu na zdalnym serwerze SP. Asercja SAML jest transportowana do SP za pośrednictwem HTTP POST.

tworzenie Kroki:

1. Użytkownik jest zalogowany do PRI.
2. Użytkownik żąda dostępu do chronionego zasobu SP. Użytkownik nie jest zalogowany na stronie SP.
3. Opcjonalnie, IdP pobiera atrybuty z magazynu danych użytkownika.
4. Usługa jednokrotnego logowania IdP zwraca formularz HTML do przeglądarki z odpowiedzią SAML zawierającą asercję uwierzytelniania i wszelkie dodatkowe atrybuty. Przeglądarka automatycznie wysyła formularz HTML z powrotem do SP.

SP Zainicjowany SSO

Z dokumentacji PingFederate: - http://documentation.pingidentity.com/display/PF610/SP-Initiated+SSO--POST-POST

W tym scenariuszu użytkownik próbuje uzyskać dostęp do chronionego zasobu bezpośrednio na stronie internetowej SP bez zalogowany. Użytkownik nie ma konta w witrynie SP, ale ma konto stowarzyszone zarządzane przez niezależnego dostawcę tożsamości. SP wysyła żądanie uwierzytelnienia do dostawcy tożsamości. Zarówno żądanie, jak i zwrócona asercja SAML są wysyłane za pośrednictwem przeglądarki użytkownika za pośrednictwem protokołu HTTP POST.

tworzenie Kroki:

1. użytkownik zażąda dostępu do chronionego zasobu Sp. Żądanie jest przekierowywane na serwer federacyjny w celu obsługi uwierzytelniania.
2. Serwer federacyjny wysyła formularz HTML z powrotem do przeglądarki, żądając SAML dla uwierzytelnienia od dostawcy tożsamości. Formularz HTML jest automatycznie publikowany w usłudze SSO dostawcy tożsamości.
3. Jeśli użytkownik nie jest już zalogowany do witryny dostawcy tożsamości lub jeśli wymagana jest ponowna autoryzacja, dostawca tożsamości prosi o poświadczenia (np., Identyfikator i hasło), a użytkownik loguje się.

4. Dodatkowe informacje o użytkowniku można pobrać z magazynu danych użytkownika w celu uwzględnienia w odpowiedzi SAML. (Te atrybuty są wstępnie określone jako część umowy federacyjnej między IdP a SP) Usługa SSO IdP zwraca formularz HTML do przeglądarki z odpowiedzią SAML zawierającą asercję uwierzytelniania i wszelkie dodatkowe atrybuty. Przeglądarka automatycznie wysyła formularz HTML z powrotem do SP. UWAGA: Specyfikacje SAML wymagają, aby odpowiedzi POST były podpisane cyfrowo.

5. (Nie pokazano) Jeśli podpis i potwierdzenie są poprawne, SP ustanawia sesję dla użytkownika i przekierowuje przeglądarkę do zasobu docelowego.

Answer 3

SP Zainicjowany SSO

SP: "Hej, wiesz Sal?"

IdP: "?! To zrobić ... Ach racja Tak, wiem Sal"

SP: ". Ok chłodny dam ją w"

IdP Zainicjowany SSO

IDP: "Hej Sal mówi mi, że znam jej"

SP: ". I nie ... Oh yeah ja będę ją wpuścić"