SAML i federacja

SAML (Security Assertion Markup Language) to oparty na XML standard wymiany danych uwierzytelniania i autoryzacji, dominujący w obszarze jednokrotnego logowania w przedsiębiorstwach.

• Umożliwia firmowemu dostawcy tożsamości potwierdzenie tożsamości użytkownika w wielu aplikacjach.
• SAML 2.0 powstał przed OIDC i nadal jest powszechnie stosowany w środowiskach B2B oraz w systemach tożsamości pracowników.

Znajomość SAML jest niezbędna do zabezpieczania federacji przedsiębiorstw, w której pojedyncza luka w zaufaniu naraża każdą połączoną aplikację.

Federacja SAML obejmuje dwie główne strony.

• Identity Provider (IdP) uwierzytelnia użytkownika i wystawia asercje (Okta, Entra ID, Ping).
• Service Provider (SP) to aplikacja, która ufa IdP i przyznaje dostęp.

Zaufanie ustanawia się poza kanałem przez wymianę metadanych, w tym certyfikatów podpisujących i adresów URL punktów końcowych.

Podstawowym elementem jest asercja — dokument XML stwierdzający, że IdP uwierzytelnił podmiot.

• Subject identyfikuje użytkownika (NameID).
• Conditions definiuje okres ważności i docelowego odbiorcę.
• AuthnStatement rejestruje sposób i czas uwierzytelnienia.
• AttributeStatement zawiera role, adres e-mail i claims grup.

Najczęściej stosowany jest przepływ SSO inicjowany przez SP.

• Użytkownik przechodzi do SP, który generuje AuthnRequest i przekierowuje do IdP.
• IdP uwierzytelnia użytkownika i wysyła metodą POST podpisaną wartość Response do usługi odbiorcy asercji (ACS) SP.
• SP weryfikuje asercję i tworzy lokalną sesję.

Bezpieczeństwo SAML opiera się na cyfrowych podpisach XML. IdP podpisuje asercję i/lub odpowiedź swoim kluczem prywatnym, a SP weryfikuje podpis za pomocą zaufanego certyfikatu.

• Należy podpisywać samą asercję, a nie tylko zewnętrzną odpowiedź.
• Należy weryfikować podpis względem przypiętego certyfikatu IdP z metadanych, a nie certyfikatu osadzonego w wiadomości.

Większość ataków na SAML wymierzona jest w logikę weryfikacji podpisu.

XML Signature Wrapping to klasa ataków na podpisy w SAML. Atakujący zachowuje prawidłowo podpisany element, ale dodaje drugą, sfałszowaną asercję, którą faktycznie odczytuje logika aplikacji.

• Podpis nadal przechodzi weryfikację dla pierwotnego fragmentu.
• Jednak logika biznesowa przetwarza wstrzykniętą, niepodpisaną asercję.

Środki zaradcze: należy używać wzmocnionej biblioteki SAML, sprawdzać, czy podpisany element jest elementem przetwarzanym przez aplikację, oraz odrzucać dokumenty zawierające wiele lub niejednoznaczne asercje.

Asercja musi być powiązana z docelowym SP. SAML zapewnia w tym celu jawne ograniczenia.

• AudienceRestriction określa identyfikator encji SP, dla którego asercja jest ważna.
• Wartość Recipient w SubjectConfirmation musi odpowiadać adresowi URL ACS.

SP musi egzekwować te ograniczenia. Pominięcie sprawdzania odbiorcy umożliwia ponowne użycie asercji wystawionej dla jednej aplikacji w innej aplikacji.

Asercje są krótkotrwałymi, jednorazowymi poświadczeniami. SP musi to egzekwować.

• Należy uwzględniać wartości NotBefore i NotOnOrAfter, stosując niewielki dopuszczalny błąd zegara.
• Należy śledzić ID asercji i odrzucać każde ponowne użycie w okresie jej ważności.
• Należy wymagać TLS na punkcie końcowym ACS.

Bez śledzenia ponownego użycia przechwycona asercja może zostać przesłana ponownie przed wygaśnięciem.

Federacja umożliwia skalowanie SSO między organizacjami, czasami za pośrednictwem hubów lub brokerów tłumaczących między protokołami.

• Każde połączenie zaufania jest potencjalnym słabym punktem; przejęty IdP pozwala podszyć się pod każdego użytkownika.
• Brokerzy tożsamości mogą łączyć SAML i OIDC, co wymaga starannego mapowania claimów.

Należy stosować zasadę najmniejszych uprawnień przy mapowaniu atrybutów i monitorować pojawianie się nieoczekiwanych nowych rejestracji SP.

Powtarzające się tryby awarii SAML, które warto audytować:

• Podpis nie jest weryfikowany albo podpisana jest odpowiedź, ale nie asercja.
• Podatność na XML Signature Wrapping.
• Brak sprawdzania odbiorcy i adresata.
• Brak ochrony przed ponownym użyciem lub zbyt długie okresy ważności.
• Parsowanie zewnętrznych encji XML (XXE) po stronie SP.
• Zaufanie certyfikatowi osadzonemu w komunikacie zamiast przypiętym metadanym.

Oba protokoły zapewniają SSO, ale różnią się konstrukcją.

• SAML XML, przeglądarkowe powiązania POST/redirect, szerokie zastosowanie w przedsiębiorstwach i środowiskach pracowniczych, dojrzałe narzędzia.
• OIDC JSON/JWT, lepsza współpraca z REST, lepszy wybór dla aplikacji mobilnych i SPA.

Wiele organizacji korzysta z obu protokołów. Osoby odpowiedzialne za bezpieczeństwo powinny znać reguły walidacji asercji dla protokołu używanego przez daną aplikację, ponieważ powierzchnia ataku jest różna.

Należy wybrać najlepszą ochronę przed opisanym atakiem.

Najważniejsze informacje:

• SAML to oparty na XML protokół korporacyjnego SSO między IdP i SP, wykorzystujący podpisane asercje.
• Bezpieczeństwo zależy od prawidłowej walidacji podpisu XML względem przypiętego certyfikatu.
• Należy chronić się przed XML Signature Wrapping, atakami powtórzeniowymi i XXE.
• Zawsze należy wymuszać ograniczenia odbiorcy i adresata oraz okresy ważności.
• Federacja skaluje zaufanie, ale zwielokrotnia zakres skutków przejęcia IdP.