SAML Basics

Support HackTricks

SAML Übersicht

Security Assertion Markup Language (SAML) ermöglicht es Identitätsanbietern (IdP), Autorisierungsanmeldeinformationen an Dienstanbieter (SP) zu senden, was Single Sign-On (SSO) erleichtert. Dieser Ansatz vereinfacht die Verwaltung mehrerer Anmeldungen, indem ein einzelnes Set von Anmeldeinformationen über mehrere Websites hinweg verwendet werden kann. Es nutzt XML für die standardisierte Kommunikation zwischen IdPs und SPs und verknüpft die Authentifizierung der Benutzeridentität mit der Dienstautorisierung.

Vergleich zwischen SAML und OAuth

  • SAML ist darauf ausgelegt, Unternehmen mehr Kontrolle über die Sicherheit von SSO-Anmeldungen zu geben.

  • OAuth ist darauf ausgelegt, mobilfreundlicher zu sein, verwendet JSON und ist eine gemeinsame Anstrengung von Unternehmen wie Google und Twitter.

SAML Authentifizierungsfluss

Für weitere Details siehe den vollständigen Beitrag von https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Dies ist eine Zusammenfassung:

Der SAML-Authentifizierungsprozess umfasst mehrere Schritte, wie im Schema dargestellt:

https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg
  1. Zugriffsversuch auf Ressource: Der Benutzer versucht, auf eine geschützte Ressource zuzugreifen.

  2. SAML-Anforderungs-Generierung: Der SP erkennt den Benutzer nicht und generiert eine SAML-Anforderung.

  3. Weiterleitung zum IdP: Der Benutzer wird zum IdP weitergeleitet, wobei die SAML-Anforderung durch den Browser des Benutzers geleitet wird.

  4. IdP erhält Anfrage: Der IdP erhält die SAML-Anforderung.

  5. Authentifizierung beim IdP: Der IdP authentifiziert den Benutzer.

  6. Benutzergültigkeit: Der IdP validiert die Legitimität des Benutzers, um auf die angeforderte Ressource zuzugreifen.

  7. SAML-Antworterstellung: Der IdP generiert eine SAML-Antwort, die notwendige Aussagen enthält.

  8. Weiterleitung zur ACS-URL des SP: Der Benutzer wird zur Assertion Consumer Service (ACS)-URL des SP weitergeleitet.

  9. Validierung der SAML-Antwort: Die ACS validiert die SAML-Antwort.

  10. Zugriff auf Ressource gewährt: Der Zugriff auf die ursprünglich angeforderte Ressource wird gewährt.

SAML-Anforderungsbeispiel

Betrachten Sie das Szenario, in dem ein Benutzer Zugriff auf eine sichere Ressource unter https://shibdemo-sp1.test.edu/secure/ anfordert. Der SP erkennt das Fehlen einer Authentifizierung und generiert eine SAML-Anforderung:

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

Der rohe SAML-Antrag sieht folgendermaßen aus:

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

Key elements of this request include:

  • AssertionConsumerServiceURL: Gibt an, wohin der IdP die SAML-Antwort nach der Authentifizierung senden soll.

  • Destination: Die Adresse des IdP, an die die Anfrage gesendet wird.

  • ProtocolBinding: Definiert die Übertragungsmethode von SAML-Protokollnachrichten.

  • saml:Issuer: Identifiziert die Entität, die die Anfrage initiiert hat.

Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.

SAML Response Example

You can find a full SAML response here. The key components of the response include:

  • ds:Signature: Dieser Abschnitt, eine XML-Signatur, gewährleistet die Integrität und Authentizität des Ausstellers der Assertion. Die SAML-Antwort im Beispiel enthält zwei ds:Signature-Elemente, eines für die Nachricht und das andere für die Assertion.

  • saml:Assertion: Dieser Teil enthält Informationen über die Identität des Benutzers und möglicherweise andere Attribute.

  • saml:Subject: Es gibt das Hauptsubjekt aller Aussagen in der Assertion an.

  • saml:StatusCode: Stellt den Status der Operation als Antwort auf die entsprechende Anfrage dar.

  • saml:Conditions: Enthält Bedingungen wie die Gültigkeitsdauer der Assertion und den angegebenen Service Provider.

  • saml:AuthnStatement: Bestätigt, dass der IdP das Subjekt der Assertion authentifiziert hat.

  • saml:AttributeStatement: Enthält Attribute, die das Subjekt der Assertion beschreiben.

Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState and SAMLResponse parameters. The ACS is responsible for processing and validating the SAML Response.

After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET request to the /secure/ endpoint and a 200 OK response, indicating successful access to the resource.

XML Signatures

XML-Signaturen sind vielseitig und können einen gesamten XML-Baum oder spezifische Elemente darin signieren. Sie können auf jedes XML-Objekt angewendet werden, nicht nur auf Antwort-Elemente. Below are the key types of XML Signatures:

Basic Structure of XML Signature

An XML Signature consists of essential elements as shown:

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

Jedes Reference-Element kennzeichnet eine spezifische Ressource, die signiert wird, identifizierbar durch das URI-Attribut.

Arten von XML-Signaturen

  1. Eingebettete Signatur: Diese Art von Signatur ist ein Nachkomme der Ressource, die sie signiert, was bedeutet, dass die Signatur innerhalb derselben XML-Struktur wie der signierte Inhalt enthalten ist.

Beispiel:

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

In einer eingebetteten Signatur gibt das ds:Transform-Element an, dass sie durch den enveloped-signature-Algorithmus eingebettet ist.

  1. Umhüllende Signatur: Im Gegensatz zu eingebetteten Signaturen umhüllen umhüllende Signaturen die Ressource, die signiert wird.

Beispiel:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
  1. Getrennte Signatur: Diese Art ist von dem Inhalt, den sie signiert, getrennt. Die Signatur und der Inhalt existieren unabhängig, aber eine Verbindung zwischen beiden wird aufrechterhalten.

Beispiel:

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

Zusammenfassend bieten XML-Signaturen flexible Möglichkeiten zur Sicherung von XML-Dokumenten, wobei jeder Typ unterschiedliche strukturelle und sicherheitstechnische Bedürfnisse erfüllt.

Referenzen

Unterstützen Sie HackTricks

Last updated