Uwierzytelnianie SAML od podszewki
SAML w single sign-on z Salesforce
W dziedzinie uwierzytelniania SAML (Security Assertion Markup Language) odgrywa kluczową rolę w zapewnianiu płynnego dostępu do wielu aplikacji. Zagłębmy się w SAML, zrozummy jego znaczenie w single sign-on (SSO) i przyjrzyjmy się jego implementacji w Salesforce.
Kontekst
Wyobraź sobie scenariusz, w którym masz dwa orgi Salesforce: dostawcę tożsamości (IDP) i dostawcę usług. Dostawca usług ma dane, do których chcesz uzyskać dostęp, ale zamiast używać wielu zestawów danych logowania, chcesz to osiągnąć jednym. Idea brzmi prosto, ale mechanika za kulisami bywa zawiła.
Kluczowe pojęcia w świecie SAML
Dostęp użytkownika: gdy użytkownik próbuje dotrzeć do chronionego zasobu u dostawcy usług, zanim się uwierzytelni.
Przekierowanie: jeśli użytkownik nie jest uwierzytelniony, dostawca usług przekierowuje go do dostawcy tożsamości za pomocą żądania SAML. W razie potrzeby razem z nim może zostać wysłany relay state (adres URL, pod który użytkownik pierwotnie chciał trafić).
Uwierzytelnianie w IDP: dostawca tożsamości weryfikuje tożsamość użytkownika, zwykle przez nazwę użytkownika, hasło albo uwierzytelnianie wieloskładnikowe.
Asercja SAML: po uwierzytelnieniu IDP wysyła asercję SAML do dostawcy usług.
Zaufanie dostawcy usług: dostawca usług weryfikuje asercję SAML, wyodrębnia informacje o użytkowniku i przyznaje dostęp. Jeśli wcześniej podano relay state, dostawca usług przechodzi pod ten konkretny adres URL.
Korzyści z single sign-on
Prostszy dostęp: użytkownicy potrzebują tylko jednego zestawu danych logowania, żeby korzystać z wielu usług.
Bezpieczeństwo: SAML używa podpisów cyfrowych, żeby zapewnić integralność danych i zapobiec manipulacjom.
Interoperacyjność: jako standardowy protokół SAML współpracuje z różnymi IDP i dostawcami usług opartymi na różnych technologiach.
Głębiej: przepływy SAML
Żądanie SAML: inicjowane przez dostawcę usług do IDP, z prośbą o uwierzytelnienie użytkownika.
Odpowiedź SAML: komunikat od IDP po uwierzytelnieniu, zawierający szczegóły dotyczące użytkownika.
Asercje: to stwierdzenia IDP o użytkowniku, obejmujące atrybuty takie jak nazwa użytkownika czy e-mail.
Podpisy cyfrowe: służą do weryfikacji asercji i zapewniają, że nie zostały nieuprawnienie zmodyfikowane.
Relay state: adres URL głębokiego linku, który zapewnia, że po uwierzytelnieniu użytkownik wróci do pierwotnie zamierzonego miejsca.
Gdy użytkownik inicjuje dostęp, do IDP wysyłane jest żądanie SAML, a IDP po weryfikacji odsyła asercję SAML. Ta asercja, po weryfikacji przez dostawcę usług, daje użytkownikowi zamierzony dostęp.
Za pomocą narzędzi takich jak SAML Tracer dla przeglądarek można zobaczyć ten przepływ. Daje to przejrzysty obraz procesu uwierzytelniania, od pierwszego żądania po końcowe przekierowanie po uwierzytelnieniu.
Zabezpieczenia w asercjach SAML
Żeby przeciwdziałać potencjalnym zagrożeniom:
Znaczniki czasu służą do zapobiegania atakom powtórzeniowym, dzięki czemu asercja SAML jest ważna tylko przez krótki czas.
Podpisy cyfrowe gwarantują, że dane nie zostały zmanipulowane podczas wymiany.
Dodatkowo asercje mogą zawierać atrybuty użytkownika, takie jak adresy e-mail czy typy użytkowników, co umożliwia bardziej szczegółową kontrolę dostępu po stronie dostawcy usług.
Podsumowanie
SAML to w swej istocie protokół oparty na XML, zawierający kluczowe elementy uwierzytelniania. Choć może wyglądać na magię, jest wynikiem przemyślanej technologii zaprojektowanej, żeby udaremniać ataki typu „man-in-the-middle” czy ataki powtórzeniowe.
Jego zdolność do łączenia wielu dostawców usług z IDP opartymi na różnych technologiach czyni go fundamentem świata cyfrowego uwierzytelniania.
Bądźmy w kontakcie
Wyrusz w swoją podróż po tożsamości w Salesforce z pewnością siebie! Więcej spostrzeżeń i wskazówek znajdziesz tutaj, na www.SteveTechArc.com, i na kanale YouTube @SteveTechArc (opens in a new tab). Zasubskrybuj i pogłębiaj swoje zrozumienie tożsamości w Salesforce.
Pomagam zmieniać świat, dzieląc się wiedzą o integracji z innymi architektami i z tymi, którzy są na drodze do architektury!
STA 3.6