SAML Przegląd

Security Assertion Markup Language (SAML) umożliwia wykorzystanie dostawców tożsamości (IdP) do przesyłania poświadczeń autoryzacyjnych do dostawców usług (SP), co ułatwia jednolity dostęp (SSO). To podejście upraszcza zarządzanie wieloma logowaniami, pozwalając na użycie jednego zestawu poświadczeń na wielu stronach internetowych. Wykorzystuje XML do standaryzowanej komunikacji między IdP a SP, łącząc uwierzytelnianie tożsamości użytkownika z autoryzacją usługi.

Porównanie SAML i OAuth

• SAML jest dostosowany do zapewnienia przedsiębiorstwom większej kontroli nad bezpieczeństwem logowania SSO.
• OAuth jest zaprojektowany z myślą o większej przyjazności dla urządzeń mobilnych, używa JSON i jest wspólnym wysiłkiem firm takich jak Google i Twitter.

Przepływ Uwierzytelniania SAML

Aby uzyskać więcej szczegółów, sprawdź pełny post z https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. To jest podsumowanie:

Proces uwierzytelniania SAML obejmuje kilka kroków, jak pokazano w schemacie:

1. Próba Dostępu do Zasobu: Użytkownik próbuje uzyskać dostęp do chronionego zasobu.
2. Generowanie Żądania SAML: SP nie rozpoznaje użytkownika i generuje Żądanie SAML.
3. Przekierowanie do IdP: Użytkownik jest przekierowywany do IdP, a Żądanie SAML przechodzi przez przeglądarkę użytkownika.
4. IdP Otrzymuje Żądanie: IdP otrzymuje Żądanie SAML.
5. Uwierzytelnianie w IdP: IdP uwierzytelnia użytkownika.
6. Walidacja Użytkownika: IdP weryfikuje legalność użytkownika do uzyskania dostępu do żądanego zasobu.
7. Tworzenie Odpowiedzi SAML: IdP generuje Odpowiedź SAML zawierającą niezbędne asercje.
8. Przekierowanie do URL ACS SP: Użytkownik jest przekierowywany do URL Usługi Konsumpcji Asercji (ACS) SP.
9. Walidacja Odpowiedzi SAML: ACS weryfikuje Odpowiedź SAML.
10. Przyznany Dostęp do Zasobu: Przyznano dostęp do początkowo żądanego zasobu.

Przykład Żądania SAML

Rozważmy scenariusz, w którym użytkownik żąda dostępu do zabezpieczonego zasobu na https://shibdemo-sp1.test.edu/secure/. SP identyfikuje brak uwierzytelnienia i generuje Żądanie SAML:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

Surowe żądanie SAML wygląda następująco:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Kluczowe elementy tego żądania obejmują:

• AssertionConsumerServiceURL: Określa, gdzie IdP powinien wysłać odpowiedź SAML po uwierzytelnieniu.
• Destination: Adres IdP, do którego wysyłane jest żądanie.
• ProtocolBinding: Definiuje metodę transmisji wiadomości protokołu SAML.
• saml:Issuer: Identyfikuje podmiot, który zainicjował żądanie.

Po wygenerowaniu żądania SAML, SP odpowiada z 302 redirect, kierując przeglądarkę do IdP z zakodowanym żądaniem SAML w nagłówku Location odpowiedzi HTTP. Parametr RelayState utrzymuje informacje o stanie przez cały czas transakcji, zapewniając, że SP rozpoznaje początkowe żądanie zasobu po otrzymaniu odpowiedzi SAML. Parametr SAMLRequest jest skompresowaną i zakodowaną wersją surowego fragmentu XML, wykorzystującą kompresję Deflate i kodowanie base64.

Przykład odpowiedzi SAML

Możesz znaleźć pełną odpowiedź SAML tutaj. Kluczowe składniki odpowiedzi obejmują:

• ds:Signature: Ta sekcja, będąca podpisem XML, zapewnia integralność i autentyczność wystawcy asercji. Odpowiedź SAML w przykładzie zawiera dwa elementy ds:Signature, jeden dla wiadomości, a drugi dla asercji.
• saml:Assertion: Ta część zawiera informacje o tożsamości użytkownika i ewentualnie inne atrybuty.
• saml:Subject: Określa główny podmiot wszystkich stwierdzeń w asercji.
• saml:StatusCode: Reprezentuje status operacji w odpowiedzi na odpowiadające żądanie.
• saml:Conditions: Szczegóły dotyczące warunków, takich jak czas ważności asercji i określony dostawca usług.
• saml:AuthnStatement: Potwierdza, że IdP uwierzytelnił podmiot asercji.
• saml:AttributeStatement: Zawiera atrybuty opisujące podmiot asercji.

Po odpowiedzi SAML proces obejmuje 302 redirect z IdP. Prowadzi to do żądania POST do adresu URL usługi konsumenckiej asercji (ACS) dostawcy usług. Żądanie POST zawiera parametry RelayState i SAMLResponse. ACS jest odpowiedzialne za przetwarzanie i walidację odpowiedzi SAML.

Po otrzymaniu żądania POST i walidacji odpowiedzi SAML, dostęp jest przyznawany do chronionego zasobu, o który początkowo prosił użytkownik. Ilustruje to żądanie GET do punktu końcowego /secure/ i odpowiedź 200 OK, wskazująca na pomyślny dostęp do zasobu.

Podpisy XML

Podpisy XML są wszechstronne, mogą podpisywać całe drzewo XML lub konkretne elementy w nim. Mogą być stosowane do dowolnego obiektu XML, nie tylko do elementów odpowiedzi. Poniżej przedstawiono kluczowe typy podpisów XML:

Podstawowa struktura podpisu XML

Podpis XML składa się z podstawowych elementów, jak pokazano:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Każdy element Reference oznacza konkretny zasób, który jest podpisywany, identyfikowalny za pomocą atrybutu URI.

Typy podpisów XML

1. Podpis osadzony: Ten typ podpisu jest potomkiem zasobu, który podpisuje, co oznacza, że podpis jest zawarty w tej samej strukturze XML co podpisana treść.

Przykład:

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

W podpisie osadzonym element ds:Transform określa, że jest on osadzony za pomocą algorytmu enveloped-signature.

2. Podpis otaczający: W przeciwieństwie do podpisów osadzonych, podpisy otaczające owijają zasób, który jest podpisywany.

Przykład:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>

3. Podpis oddzielony: Ten typ jest oddzielony od treści, którą podpisuje. Podpis i treść istnieją niezależnie, ale utrzymywany jest między nimi link.

Przykład:

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

Podsumowując, podpisy XML oferują elastyczne sposoby zabezpieczania dokumentów XML, z każdym typem spełniającym różne potrzeby strukturalne i bezpieczeństwa.

Odniesienia

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/