Czym jest Security Assertion Markup Language (SAML)?
- Słownik IAM
- Czym jest Security Assertion Markup Language (SAML)?
Security Assertion Markup Language (SAML) to otwarty, oparty na formacie XML standard, który umożliwia dostawcy tożsamości (IdP) bezpieczne przekazywanie danych uwierzytelniających i autoryzacyjnych użytkownika do dostawcy usług (SP). Mówiąc najprościej: SAML to jedna z głównych technologii, która pozwala użytkownikom zalogować się raz i uzyskać dostęp do wielu aplikacji bez ponownego wprowadzania danych logowania.
Do czego służy SAML?
Standard SAML zazwyczaj stosuje się wszędzie tam, gdzie użytkownicy potrzebują bezpiecznego i płynnego dostępu do wielu aplikacji. Najczęstsze przypadki użycia to:
- Logowanie jednokrotne (SSO): jedno logowanie zapewnia dostęp do wielu aplikacji, eliminując konieczność ponownego wprowadzania danych uwierzytelniających dla każdej usługi.
- Tożsamość federacyjna: SAML umożliwia organizacji uznawanie tożsamości wydanych przez firmę partnerską lub nadrzędną, dzięki czemu użytkownicy z zaufanej domeny uzyskują dostęp bez konieczności posiadania oddzielnych kont.
- Zarządzanie dostępem w przedsiębiorstwie: zespoły IT uzyskują centralną kontrolę nad tym, kto ma dostęp do poszczególnych aplikacji, kierując logowania przez jednego dostawcę IdP, co pomaga egzekwować spójne zasady, takie jak uwierzytelnianie wieloskładnikowe (MFA), wszędzie jednocześnie.
W każdym przypadku użycia IdP wystawia podpisaną asercję XML, która trafia do SP za pośrednictwem przeglądarki użytkownika, dzięki czemu dane uwierzytelniania są bezpiecznie przesyłane bez konieczności ponownego logowania się użytkownika.
Kluczowe elementy SAML
Wymiana SAML zazwyczaj wiąże się ze współpracą kilku elementów. Oto kilka podstawowych pojęć, które znacznie ułatwiają zrozumienie procesu uwierzytelniania:
- Podmiot główny (subject): użytkownik, który jest uwierzytelniany — zazwyczaj osoba próbująca uzyskać dostęp do określonej aplikacji.
- Dostawca tożsamości (IdP): system, który weryfikuje użytkownika i wystawia asercję, np. Microsoft Entra ID lub Okta, aby umożliwić faktyczne logowanie.
- Dostawca usług (SP): aplikacja lub witryna internetowa, do której użytkownik chce uzyskać dostęp, polegająca na IdP w zakresie potwierdzenia tożsamości użytkownika zamiast zarządzania danymi logowania.
- Asercja SAML: podpisane oświadczenie XML, które IdP wysyła do SP, zawierające dane dotyczące tożsamości i autoryzacji użytkownika (więcej informacji poniżej).
- Metadane: konfiguracja, którą obie strony wymieniają z wyprzedzeniem — punkty końcowe, certyfikaty itp. — aby wykazać, że IdP i SP wiedzą, jak ufać sobie nawzajem i komunikować się ze sobą.
- Certyfikat podpisujący: certyfikat cyfrowy zawierający klucz publiczny, którego SP używa do weryfikacji podpisu asercji, ustanawiający zaufanie między SP a IdP w celu potwierdzenia, że asercja nie została zmieniona podczas przesyłania.
Jak działa uwierzytelnianie SAML?
Uwierzytelnianie SAML działa poprzez przekazanie podpisanej asercji z IdP do SP, co potwierdza, że użytkownik jest tym, za kogo się podaje. Przepływ inicjowany przez SP jest najczęstszą wersją uwierzytelniania SAML i rozpoczyna się, gdy użytkownik przechodzi na stronę internetową lub do aplikacji, z której chce skorzystać. Jeśli aplikacja korzysta z zewnętrznego IdP do logowania, przekierowuje przeglądarkę użytkownika do IdP z żądaniem uwierzytelnienia SAML. Następnie IdP sprawdza dane uwierzytelniające użytkownika, aby go uwierzytelnić — jeśli użytkownik ma już aktywną sesję, ten krok jest pomijany. Po pomyślnej weryfikacji przez IdP generuje on podpisaną asercję i przesyła ją z powrotem za pośrednictwem przeglądarki do SP. Na koniec SP weryfikuje podpis asercji, ufa mu i wpuszcza użytkownika bez konieczności osobnego logowania. Chociaż uwierzytelnianie inicjowane przez SP jest najczęstsze w przypadku SAML, istnieje również przepływ inicjowany przez IdP, w którym użytkownik zaczyna od IdP, na przykład klikając kafelek aplikacji w firmowym pulpicie nawigacyjnym.
Czym jest asercja SAML?
Asercja SAML to podpisany dokument XML, który IdP wysyła do SP w celu poświadczenia tożsamości użytkownika. Każda asercja może zawierać jedną lub wiele deklaracji, które stanowią właściwe informacje wykorzystywane przez SP do podjęcia decyzji o przyznaniu użytkownikowi dostępu. Istnieją trzy typy deklaracji:
- Deklaracje uwierzytelniania potwierdzają, kim jest użytkownik, kiedy się zalogował i w jaki sposób (tj. czy użyto MFA).
- Deklaracje atrybutów zawierają dodatkowe informacje o użytkowniku, takie jak jego rola lub dział. SP może wykorzystać te atrybuty, aby zdecydować, co użytkownik może widzieć lub robić.
- Deklaracje decyzji o autoryzacji określają, czy użytkownikowi przyznano dostęp do określonego zasobu. Ten rodzaj deklaracji jest rzadko stosowany, ponieważ bardziej złożona autoryzacja jest zwykle obsługiwana przez standard eXtensible Access Control Markup Language (XACML).
SAML a inne standardy uwierzytelniania
Standard SAML jest często kojarzony z innymi protokołami tożsamości i dostępu, które pełnią powiązane, ale odmienne funkcje. Głównym celem SAML jest obsługa uwierzytelniania, czyli potwierdzanie tożsamości użytkownika oraz sprawdzanie, czy ma on prawo dostępu do strony internetowej lub aplikacji. Uwierzytelnianie odróżnia go od protokołu OAuth, który służy do autoryzacji i przyznaje aplikacji uprawnienia dostępu do określonych zasobów. Protokoły SAML i OAuth wzajemnie się uzupełniają, a nie konkurują ze sobą — SAML potwierdza tożsamość, a OAuth przyznaje dostęp.
OpenID Connect (OIDC) jest bardziej podobny do SAML, ponieważ oba protokoły uwierzytelniają użytkowników i umożliwiają logowanie jednokrotne (SSO). Jednak OIDC to warstwa uwierzytelniania oparta na OAuth, która wykorzystuje tokeny JSON Web Token (JWT) dostosowane do nowoczesnych aplikacji internetowych i mobilnych, podczas gdy oparte na formacie XML podejście SAML jest nadal szeroko stosowane w korporacyjnych rozwiązaniach SSO dla sieci Web, chociaż to OIDC coraz częściej stanowi domyślny wybór w przypadku nowych aplikacji. Dla porównania Lightweight Directory Access Protocol (LDAP) to starszy protokół katalogowy, który powstał przed erą chmury i jest przeznaczony dla środowisk lokalnych (on-premises). Zamiast konkurować z SAML, LDAP często funkcjonuje za dostawcą tożsamości SAML (IdP) jako źródło danych uwierzytelniających użytkowników.
| SAML | OAuth | OIDC | LDAP | |
|---|---|---|---|---|
| Działanie | Uwierzytelnianie i logowanie jednokrotne (SSO) | Autoryzacja | Uwierzytelnianie (w OAuth) | Dostęp do katalogów |
| Format | Podpisana asercja XML | Token dostępu | JWT | Zapytania do katalogu |
| Najbardziej odpowiednie dla | Firmowe logowanie SSO do aplikacji internetowych | Delegowany dostęp do API | Aplikacje mobilne i natywne dla chmury | Lokalne katalogi |
SAML
OAuth
OIDC
LDAP
Zalety i wady protokołu SAML
SAML ma zarówno wiele zalet, jak i kompromisów, które warto zrozumieć przed jego wdrożeniem.
Zalety standardu SAML
Największą zaletą standardu SAML jest to, że minimalizuje liczbę haseł, którymi użytkownicy muszą zarządzać. Dzięki jednemu logowaniu, które zapewnia dostęp do wielu aplikacji, użytkownicy mają mniej danych uwierzytelniających do zapamiętania, co minimalizuje powierzchnię ataku i zmniejsza ryzyko kradzieży danych uwierzytelniających. Ponieważ uwierzytelnianie odbywa się za pośrednictwem jednego IdP, organizacje zyskują również scentralizowaną kontrolę nad zasadami; zespoły ds. bezpieczeństwa mogą konsekwentnie egzekwować MFA we wszystkich połączonych aplikacjach z jednego miejsca. Taka centralizacja przynosi korzyści, obniżając koszty działu pomocy technicznej dzięki zmniejszeniu liczby zgłoszeń dotyczących resetowania haseł, które zwykle przytłaczają wsparcie IT.
Wady standardu SAML
Zalety SAML ujawniają się tylko wtedy, gdy język znaczników jest prawidłowo skonfigurowany. Opiera się na XML Signature i XML Encryption w celu zapewnienia integralności i poufności wiadomości, a także na TLS w celu zabezpieczenia transportu. Jedna z najczęstszych luk w zabezpieczeniach standardu SAML dotyczy błędnej konfiguracji, takiej jak nieprawidłowa weryfikacja podpisów. Jego oparty na XML model jest mniej elastyczny niż nowoczesne formaty tokenów, co sprawia, że wdrożenie SAML jest trudne w przypadku aplikacji mobilnych i jednostronicowych.