Bezpieczeństwo Salesforce bez tajemnic: konfiguracja SAML i przepływ SSO
W świecie Salesforce zrozumienie mechaniki bezpieczeństwa i tożsamości przy single sign-on (SSO) może mieć duże znaczenie. Przyjrzyjmy się dokładnie, jak działa Salesforce jako dostawca usług pod zewnętrznym dostawcą tożsamości (IDP), z naciskiem na kluczowe konfiguracje i przepływy.
Konfiguracja w szczegółach:
Kluczowa rola przeglądarki: w naszym zintegrowanym ekosystemie przeglądarka nie jest zwykłym widzem; to aktywny pośrednik, który umożliwia bezpieczną komunikację między IDP a Salesforce, czyli dostawcą usług.
Dialogi SAML: komunikacja w SSO polega na wysyłaniu żądań SAML do IDP. W odpowiedzi oczekiwane są asercje SAML, czyli w istocie cyfrowe „dowody” uwierzytelnienia.
Zaufanie dzięki certyfikatowi cyfrowemu: żeby interakcje były bezpieczne i zaufane, Salesforce i IDP wymieniają certyfikat cyfrowy. Ten elektroniczny uścisk dłoni jest fundamentem ich bezpiecznej relacji.
Konfiguracja krok po kroku:
[caption id="" align=“alignnone” width=“1780”]
Konfiguracja SAML [/caption]
Po stronie IDP: konfiguracja obejmuje utworzenie connected app, ustalenie szczegółów certyfikatu cyfrowego i wpisanie ścieżek przekierowań (URL redirect) do dostawcy usług.
Po stronie Salesforce: kroki obejmują sprawdzenie, czy skonfigurowano „My Domain”, włączenie SAML i kluczowy krok, czyli wgranie certyfikatu IDP. Niezbędna jest też konfiguracja przekierowań z powrotem do IDP.
Tożsamość użytkownika przez Federation ID: Salesforce jednoznacznie rozpoznaje użytkowników z IDP po Federation ID. To coś w rodzaju specjalnej etykiety, takiej jak numer pracownika albo inny unikalny identyfikator, która ułatwia płynną identyfikację użytkownika.
SSO Flow w szczegółach:
[caption id="" align=“alignnone” width=“1780”]
Przepływ logowania inicjowany przez SP [/caption]
1a/1b Pierwsze wejście użytkownika: na początku dnia użytkownik próbuje otworzyć zabezpieczony zasób Salesforce. Jeśli nie jest zalogowany, Salesforce to wykrywa i wydaje polecenie przekierowania.
2a Podróż do IDP: Salesforce przekierowuje użytkownika do jego IDP. Tu zaczyna się właściwa podróż: od tradycyjnych ekranów logowania po bardziej zaawansowane metody, takie jak uwierzytelnianie wieloskładnikowe.
2b Pieczęć IDP: gdy tożsamość użytkownika zostanie potwierdzona, IDP tworzy i wysyła do Salesforce asercję SAML, która za użytkownika ręczy.
3a/3b/4 Drzwi Salesforce otwarte: po otrzymaniu zgody od IDP Salesforce przeprowadza własną weryfikację, a potem uruchamia sesję. Dla użytkownika wszystko jest płynne: klika link do Salesforce, przechodzi uwierzytelnienie i gotowe, trafia na swoją stronę w Salesforce.
Podsumowanie
Płynne doświadczenie to kluczowy element tego tańca, czyli przepływu inicjowanego przez dostawcę usług (Service Provider Initiated Flow). Użytkownicy, którzy idą prosto do Salesforce, robią krótki objazd: trafiają do uwierzytelnienia, a po weryfikacji płynnie wracają do Salesforce.
Ta harmonijna współpraca Salesforce, IDP i przeglądarek użytkowników może wydawać się zawiła, ale ma zachować równowagę między zabezpieczeniami a szybkim dostępem użytkowników.
Wypatruj kolejnych wpisów, w których zagłębimy się w wyspecjalizowane zagadnienia, takie jak intrygujący świat deep linków i relay state. Dla osób, które wolą praktyczne demonstracje, przygotowuję szczegółowe filmy pokazujące konfigurację w środowiskach orgów Salesforce.
Po takie treści i więcej zasubskrybuj kanał @SteveTecharc na YouTube. Przejdźmy razem przez labirynt bezpieczeństwa Salesforce!
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!
Bądźmy ciekawi i bezpieczni!
STA 3.4