saml-2.0 Samouczek
Rozpoczęcie pracy z saml-2.0
Szukaj…
Uwagi
SAML2.0 to otwarty standard służący do przesyłania danych uwierzytelniających i autoryzacyjnych między dostawcami usług a dostawcami tożsamości.
Najczęstszym zastosowaniem jest internetowe logowanie jednokrotne, gdzie SAML umożliwia zalogowanie się do aplikacji przy użyciu poświadczeń z innego systemu, bez konieczności bezpośredniego łączenia się dwóch systemów podczas uwierzytelniania.
Przepływ uwierzytelniania SAML2.0
SAML określa trzy kluczowe role:
The Identity Provider (IdP)
Strona, która zapewnia i utrzymuje tożsamość użytkowników. Może to być usługa katalogowa, taka jak ADFS lub niestandardowe rozwiązanie dla bazy danych.
The Service Provider (SP)
Usługodawca to faktyczna usługa, do której użytkownik próbuje się zalogować. Może to być strona internetowa, aplikacja lub dowolna usługa, do której zalogowania powinien być wymagany użytkownik.
Główny / użytkownik
Rzeczywisty użytkownik inicjujący żądanie lub próbujący uzyskać dostęp do zasobu od usługodawcy (SP).
Głównym przypadkiem użycia SAML jest internetowe logowanie jednokrotne , w którym proces SAML jest przeprowadzany przez zestaw przekierowań w przeglądarce użytkownika, gdzie użytkownik działa jako nośnik tokenów między IdP a SP.
Istnieją dwa przepływy dla jednokrotnego logowania przez Internet przy użyciu SAML:
Zainicjowano dostawcę tożsamości (IdP)
Użytkownik loguje się do IdP, a następnie jest przesyłany do wybranego SP. Na przykład użytkownik loguje się do firmowego intranetu i jest prezentowany ze wszystkimi dostępnymi aplikacjami.
Zainicjowano Usługodawcę (SP)
Użytkownik próbuje zalogować się do aplikacji, ale zostaje przekierowany do dostawcy tożsamości w celu wykonania rzeczywistego uwierzytelnienia. Na przykład użytkownik próbuje zalogować się do zdalnej aplikacji SaaS , ale zostaje przekazany do korporacyjnego dostawcy tożsamości, aby mógł zalogować się przy użyciu swoich poświadczeń korporacyjnych do zdalnej aplikacji.
Przepływ inicjowany przez SP jest znacznie wizualizowany przez poniższy przepływ pracy:
Źródło: Wikipedia
- Użytkownik próbuje uzyskać dostęp do zasobu w określonej aplikacji lub stronie internetowej
- Użytkownik określa użytkowników, którzy próbują się zalogować przy użyciu zewnętrznego IDP. SP wygeneruje asercję SAML i przekaże ją dalej (zwykle poprzez zmienne POST lub GET) podczas przekierowania do IdP
- Użytkownik uwierzytelni się sam w stosunku do IdP
- Podpisane potwierdzenie i token są generowane przez IdP
- Podpisane potwierdzenie i token są przekazywane z powrotem (ponownie przy użyciu zmiennych POST lub GET) do SP, a jeśli zakończy się powodzeniem, sesja zostanie zainicjowana na SP
- a ponadto użytkownik jest w stanie zażądać dodatkowych zasobów od SP, podczas gdy ma aktywną sesję z SP (tj. za pomocą plików cookie), więc nie musi uwierzytelniać się za pomocą IdP przy każdym żądaniu.
Narzędzia do debugowania SAML
Biorąc pod uwagę wszystkie żądania i stwierdzenia, debugowanie problemów z oświadczeniami i twierdzeniami SAML może być kłopotliwe.
Ponieważ w SAML podstawowa zasada nie wymaga bezpośredniego połączenia między IdP a SP, przeglądarka użytkownika działa jako nośnik wiadomości między nimi. Z tego powodu cała komunikacja - choć zaszyfrowana - odbywa się za pośrednictwem własnej przeglądarki.
Za pomocą różnych narzędzi do debugowania można zobaczyć dokładną komunikację i wysyłane żądania oraz przekazywane między IdP a SP.
Aby rozpocząć, oto kilka narzędzi dla różnych przeglądarek, które powinny zacząć:
Chrom
Firefox
Używając na przykład SAML Tracer , możesz zobaczyć odkodowane asercje i żądania SAML w czasie rzeczywistym podczas testowania i debugowania