SAML Übersicht

Security Assertion Markup Language (SAML) ermöglicht es Identitätsanbietern (IdP), Autorisierungsanmeldeinformationen an Dienstanbieter (SP) zu senden, was die Nutzung von 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 mobilerfreundlicher, 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:

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 Assertions 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 der Authentifizierung und generiert eine SAML-Anforderung:

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

Die rohe SAML-Anfrage sieht folgendermaßen aus:

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

Wesentliche Elemente dieser Anfrage sind:

• 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.

Nach der Generierung der SAML-Anfrage antwortet der SP mit einem 302 Redirect, der den Browser mit der in den HTTP-Antwort-Header Location kodierten SAML-Anfrage zum IdP leitet. Der RelayState-Parameter hält die Statusinformationen während der Transaktion aufrecht und stellt sicher, dass der SP die ursprüngliche Ressourcenanforderung beim Empfang der SAML-Antwort erkennt. Der SAMLRequest-Parameter ist eine komprimierte und kodierte Version des rohen XML-Ausschnitts, die Deflate-Kompression und Base64-Kodierung verwendet.

SAML-Antwortbeispiel

Sie finden eine vollständige SAML-Antwort hier. Die wichtigsten Komponenten der Antwort sind:

• 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: Er 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 Details zu Bedingungen wie die Gültigkeitsdauer der Assertion und den angegebenen Dienstanbieter.
• saml:AuthnStatement: Bestätigt, dass der IdP das Subjekt der Assertion authentifiziert hat.
• saml:AttributeStatement: Enthält Attribute, die das Subjekt der Assertion beschreiben.

Nach der SAML-Antwort umfasst der Prozess einen 302-Redirect vom IdP. Dies führt zu einer POST-Anfrage an die Assertion Consumer Service (ACS) URL des Dienstanbieters. Die POST-Anfrage enthält die Parameter RelayState und SAMLResponse. Die ACS ist verantwortlich für die Verarbeitung und Validierung der SAML-Antwort.

Nachdem die POST-Anfrage empfangen und die SAML-Antwort validiert wurde, wird der Zugriff auf die geschützte Ressource gewährt, die ursprünglich vom Benutzer angefordert wurde. Dies wird mit einer GET-Anfrage an den /secure/-Endpunkt und einer 200 OK-Antwort veranschaulicht, die den erfolgreichen Zugriff auf die Ressource anzeigt.

XML-Signaturen

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. Nachfolgend sind die wichtigsten Typen von XML-Signaturen aufgeführt:

Grundstruktur der XML-Signatur

Eine XML-Signatur besteht aus wesentlichen Elementen, wie gezeigt:

<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. Enveloped Signature: 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 enveloped signature gibt das ds:Transform-Element an, dass es durch den enveloped-signature-Algorithmus umschlossen ist.

2. Enveloping Signature: Im Gegensatz zu enveloped signatures umschließen enveloping signatures die Ressource, die signiert wird.

Beispiel:

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

3. Detached Signature: 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.

References

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