Uprość integrację uwierzytelniania SAML dla deweloperów
Dowiedz się, czym jest SAML, jak wdrożyć SSO i poznaj szybkie kroki integracji uwierzytelniania SAML jako dostawca tożsamości (IdP) lub dostawca usług (SP).
RanProduct & Design
Przestań tracić tygodnie na uwierzytelnianie użytkowników
Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.
Single Sign-On (SSO) to klucz dla nowoczesnych aplikacji, a SAML umożliwia bezpieczne, przyjazne uwierzytelnianie w ramach systemów tożsamości biznesowej. Ten przewodnik upraszcza SAML dla programistów i projektantów — prezentuje jasne kroki i praktyczne przykłady, które pomogą ci wdrożyć SAML efektywnie.
Security Assertion Markup Language (SAML) to standard oparty na XML, używany do wymiany danych uwierzytelniających i autoryzacyjnych między dwoma kluczowymi graczami: Dostawcą Tożsamości (IdP) oraz Dostawcą Usług (SP). Jest to popularne rozwiązanie Single Sign-On (SSO) w organizacjach — użytkownicy korporacyjni mogą zalogować się tylko raz i korzystać z wielu aplikacji.
Dostawca Tożsamości (IdP) odpowiada za zarządzanie i weryfikowanie danych uwierzytelniających użytkownika, takich jak nazwy użytkownika i hasła. Kiedy użytkownik próbuje uzyskać dostęp do chronionej usługi, IdP potwierdza jego tożsamość i przesyła to potwierdzenie do usługi.
Przykład: Wyobraź sobie, że pracujesz w dużej firmie zarządzającej kontami pracowników przez Microsoft Azure AD. Podczas próby zalogowania do Salesforce, Azure AD działa jako IdP. Sprawdza twoje dane i informuje Salesforce, że możesz korzystać z tej aplikacji.
Dostawca Usług (SP) to aplikacja lub usługa, do których użytkownicy faktycznie próbują się dostać. Polega na IdP, które wykonuje główną „pracę” uwierzytelniającą.
Przykład: Kontynuując powyższy scenariusz, Salesforce to SP. Polega na Microsoft Azure AD (IdP), aby potwierdzić twoją tożsamość. Gdy Azure AD potwierdzi twoją autoryzację, Salesforce wpuszcza cię do środka.
Mówiąc o „aplikacji SAML”, zazwyczaj chodzi o SP.
Dzięki protokołowi SAML możesz skonfigurować swoją usługę jako IdP, by obsługiwać integracje aplikacji (np. Azure AD / Google Workspace) lub jako SP (np. Salesforce / Slack), by oferować użytkownikom SSO.
Asercja SAML to serce protokołu SAML. To cyfrowa „notka”, którą tworzy IdP i przesyła do SP, oznajmiając: „Potwierdziłem tożsamość tego użytkownika”. Dalej omówimy, jak przebiega cały proces zarówno dla IdP, jak i SP.
Gdy twoja usługa pełni rolę IdP, umożliwiasz uwierzytelnianie SAML w wielu aplikacjach. Użytkownicy mogą korzystać z wielu usług za pomocą jednej, firmowej tożsamości.
Oto typowy przebieg SSO SAML dla IdP:
Użytkownik próbuje uzyskać dostęp do aplikacji (SP), np. Salesforce.
Aplikacja przekierowuje użytkownika do twojego IdP w celu uwierzytelnienia.
Użytkownik podaje swoje dane logowania na stronie IdP.
IdP sprawdza wprowadzone dane.
Jeżeli dane są poprawne, IdP wysyła asercję SAML z powrotem do SP.
SP przetwarza asercję, potwierdza jej ważność i nadaje użytkownikowi dostęp.
Jeśli twoja usługa pełni funkcję SP, zintegrujesz ją z różnymi dostawcami tożsamości, by umożliwić użytkownikom SSO. Dzięki temu użytkownicy biznesowi z różnych organizacji lub tenantów mogą bezpiecznie korzystać z twojej aplikacji.
Przebieg SSO inicjowany po stronie SP:
Użytkownik próbuje zalogować się do twojej aplikacji.
Twoja aplikacja generuje żądanie SAML i przekierowuje użytkownika na stronę logowania IdP.
Użytkownik loguje się w IdP (lub pomija ten krok, jeśli już jest zalogowany).
IdP weryfikuje tożsamość użytkownika i po potwierdzeniu pakuje dane użytkownika w asercję SAML.
IdP przesyła asercję z powrotem do twojej aplikacji.
Twoja usługa weryfikuje asercję. Jeśli jest poprawna, użytkownik otrzymuje dostęp do aplikacji.
IdP Entity ID: Unikalny identyfikator IdP w komunikacji SAML, swego rodzaju cyfrowa plakietka z imieniem.
SSO URL: Punkt dostępu (URL), na który SP przekierowuje użytkowników w celu uwierzytelnienia.
Certyfikat X.509: Klucz publiczny używany do podpisywania asercji SAML — zabezpiecza je i potwierdza autentyczność.
Wskazówka: Jeśli twój IdP oferuje SAML Metadata URL, integracja jest prostsza. Pod tym URL znajdziesz wszystkie potrzebne informacje (certyfikaty, SSO URL, IdP Entity ID). Pozwala to uniknąć błędów przy kopiowaniu i ręcznym aktualizowaniu certyfikatów.
Format NameID: Definiuje format identyfikatora użytkownika (np. adres e-mail lub nazwę użytkownika).
Atrybuty SAML: Dodatkowe dane o użytkowniku, np. rola, e-mail czy dział, które IdP przesyła do SP.
Przykład: Jeśli asercja SAML podpisana przez IdP zawiera email ([email protected]), role (admin) i department (engineering), SP może użyć role do nadania uprawnień administratora lub department do przypisania do odpowiedniego zespołu. Aby prawidłowo przekazać te dane, IdP i SP muszą ustalić mapowanie atrybutów — np. IdP określa „department” jako team, a SP oczekuje group. Poprawne mapowanie to klucz do spójnej komunikacji.
Szyfrowane asercje (opcjonalnie): Dla ochrony wrażliwych danych, asercje SAML można szyfrować.
Rola IdP: Szyfruje asercję publicznym kluczem SP.
Rola SP: Odszyfrowuje asercję swoim kluczem prywatnym, by odczytać dane użytkownika.
Masz już wszystkie niezbędne informacje do uruchomienia połączenia SAML. Żeby zintegrować Salesforce (SP) z Azure AD (IdP), wykonaj następujące kroki:
Uzyskaj IdP Entity ID, SSO URL i certyfikat z Azure AD, po czym wprowadź je w Salesforce.
Logto pozwala innym aplikacjom korzystać z federacyjnego uwierzytelniania tożsamości i obsługuje wieloskładnikowe uwierzytelnianie (MFA) dla zwiększenia bezpieczeństwa.
Skonfiguruj parametry SAML
Skonfiguruj aplikację, podając ACS URL i SP Entity ID (dostawcy usług).
Udostępnij Metadata URL
Logto udostępnia IdP Metadata URL, z którego dostawcy usług mogą automatycznie pobrać niezbędne dane — jak SSO URL i certyfikaty.
Zaawansowana konfiguracja (opcjonalnie)
Możesz utworzyć wiele nowych certyfikatów z odciskami palca i ustalić daty wygaśnięcia, ale aktywny zawsze jest tylko jeden certyfikat.
Zmień format Name ID według potrzeb biznesowych.
Włącz szyfrowanie asercji SAML poprzez kopiowanie i wklejanie certyfikatu x509 od dostawcy usług.
Mapowanie atrybutów (opcjonalnie)
Łatwo dostosuj sposób udostępniania danych użytkownika dostawcom usług (SP).
Szczegółowe wskazówki znajdziesz w oficjalnej dokumentacji: Aplikacja SAML
Logto integruje się także z dowolnym IdP korporacyjnym przez SAML lub OIDC. Niezależnie od tego, czy aktywujesz SSO inicjowane przez SP dla własnych stron logowania, czy konfigurujesz SSO inicjowane przez IdP — proces jest prosty.
Utwórz konektor enterprise
Przejdź do Logto Console > Enterprise SSO i utwórz nowy konektor enterprise. Wybierz SAML jako standard protokołu.
Skonfiguruj parametry SAML
Podaj metadata URL lub plik metadata XML z twojego IdP. Jeśli metadane nie są dostępne, przejdź na konfigurację ręczną: wpisz IdP Entity ID, SSO URL i załaduj certyfikat podpisu.
Podaj adresy ACS URL i SP Entity ID
Podaj ACS URL i SP Entity ID od Logto swojemu IdP, by zakończyć konfigurację integracji.
Mapowanie atrybutów (opcjonalnie)
Skonfiguruj mapowanie danych użytkownika — np. e-mail czy imiona — by informacje były poprawnie przekazywane z IdP do Logto.
Dodaj domeny e-mail firmowe
W zakładce „SSO Experience” konektora enterprise dodaj jedną lub więcej domen e-mail. Pozwala to, by tylko użytkownicy z podanych domen mogli uwierzytelniać się przez SSO.
Włącz SSO inicjowane przez IdP (opcjonalnie)
Włącz SSO inicjowane przez IdP tylko, jeśli wymagają tego klienci biznesowi. Funkcja ta pozwala użytkownikom logować się do twoich aplikacji bezpośrednio z pulpitu IdP.
SAML zapewnia standardową, bezpieczną metodę SSO, usprawniając uwierzytelnianie. Logto upraszcza ten proces — bez względu na to, czy działasz jako IdP, czy SP. Przyjazny interfejs oraz wsparcie zarówno dla chmury, jak i wersji open-source sprawiają, że Logto eliminuje złożoność integracji SAML. Wystarczy skonfigurować kilka parametrów, aby połączyć swoje usługi z dowolnym IdP czy SP SAML i skupić się na tworzeniu doskonałych doświadczeń dla swoich użytkowników.
