Anforderungen werden oft in Bezug auf (gegenseitige) Authentifizierung, Integrität und Vertraulichkeit formuliert, wobei die Wahl des Sicherheitsmechanismus den Implementierern und Bereitstellern überlassen bleibt. Der primäre SAML-Anwendungsfall heißt Web Browser Single Sign-On (SSO). Ein Benutzer verwendet einen Benutzeragenten (normalerweise einen Webbrowser) und fordert eine Webressource an, die durch einen SAML-Dienstanbieter geschützt ist. Der Dienstanbieter, der die Identität des anfragenden Benutzers erfahren möchte, sendet über den Benutzeragenten eine Authentifizierungsanfrage an einen SAML-Identitätsanbieter.
Allgemeine SAML-Sicherheit
In den folgenden Abschnitten werden die Sicherheitsrisiken bei der Verwendung und Implementierung von SAML analysiert und Gegenmaßnahmen beschrieben, mit denen das miniOrange SAML SSO-Plugin/Modul die Risiken mindert.
- SAML-Behauptungen:
Auf der Ebene der SAML-Behauptung selbst gibt es wenig zu Sicherheitsbedenken zu sagen – die meisten Bedenken entstehen bei der Kommunikation im Anfrage-/Antwortprotokoll oder beim Versuch, SAML über eine der Bindungen zu verwenden. Vom Verbraucher wird natürlich immer erwartet, dass er das Gültigkeitsintervall der Behauptung und alle in der Behauptung enthaltenen Elemente respektiert. Ein Problem auf der Ebene der Behauptung bedarf jedoch einer Analyse: Eine Behauptung liegt, sobald sie ausgegeben wurde, außerhalb der Kontrolle des Ausstellers. Diese Tatsache hat mehrere Konsequenzen. Beispielsweise hat der Aussteller keine Kontrolle darüber, wie lange die Behauptung in den Systemen des Verbrauchers bestehen bleibt; Der Emittent hat auch keine Kontrolle über die Parteien, mit denen der Verbraucher/Dienstleister die Behauptungsinformationen teilt. Diese Bedenken gehen über die Bedenken hinsichtlich eines böswilligen Angreifers hinaus, der den Inhalt von Behauptungen sehen kann, die unverschlüsselt (oder unzureichend verschlüsselt) über die Leitung übertragen werden. Obwohl Anstrengungen unternommen wurden, um viele dieser Probleme innerhalb der SAML-Spezifikation anzugehen, wird nichts in der Spezifikation die Anforderung einer sorgfältigen Überlegung darüber, was in eine Behauptung aufgenommen werden soll, außer Kraft setzen. Emittenten sollten jederzeit die möglichen Konsequenzen berücksichtigen, wenn die Informationen in der Behauptung an einem entfernten Standort gespeichert werden, wo sie direkt missbraucht oder potenziellen Hackern ausgesetzt oder möglicherweise für kreativere betrügerische Zwecke gespeichert werden können. Emittenten sollten auch die Möglichkeit in Betracht ziehen, dass die in der Behauptung enthaltenen Informationen mit anderen Parteien geteilt oder sogar absichtlich oder versehentlich veröffentlicht werden könnten.
1.1 SAML-Protokoll:
In den folgenden Abschnitten werden Sicherheitsüberlegungen für das SAML-Request-Response-Protokoll selbst beschrieben, abgesehen von etwaigen Bedrohungen, die sich aus der Verwendung einer bestimmten Protokollbindung ergeben.
1.1.1 Denial of Service:
Das SAML-Protokoll ist anfällig für einen Denial-of-Service-Angriff (DOS). Die Bearbeitung einer SAML-Anfrage ist möglicherweise ein sehr kostspieliger Vorgang, einschließlich des Parsens der Anforderungsnachricht (in der Regel mit der Erstellung eines DOM-Baums), der Datenbank-/Assertionsspeichersuche (möglicherweise auf einem nicht indizierten Schlüssel), der Erstellung einer Antwortnachricht und möglicherweise einer oder mehreren digitale Signaturoperationen. Daher ist der Aufwand, den ein Angreifer beim Generieren von Anfragen benötigt, viel geringer als der Aufwand, der für die Bearbeitung dieser Anfragen erforderlich ist.
1.1.2 Signierte Anfragen erforderlich
Das miniOrange SAML SSO-Plugin/Modul signiert die Anfrage und schränkt außerdem die Reihenfolge der Asymmetrie zwischen der vom SAML-Plugin und dem Responder geleisteten Arbeit ein. Die zusätzliche Arbeit, die der Responder zur Überprüfung der Signatur benötigt, macht einen relativ kleinen Prozentsatz der Gesamtarbeit aus, die der Responder benötigt, während der Prozess der Berechnung der digitalen Signatur einen relativ großen Arbeitsaufwand für den Anforderer darstellt. Die Verringerung dieser Asymmetrie verringert das mit einem DOS-Angriff verbundene Risiko. Beachten Sie jedoch, dass ein Angreifer theoretisch eine signierte Nachricht abfangen und sie dann kontinuierlich wiedergeben kann, wodurch diese Anforderung umgangen wird. Diese Situation kann vermieden werden, indem die Verwendung des XML-Signaturelements vorgeschrieben wird einen Zeitstempel enthalten; Anhand des Zeitstempels kann dann festgestellt werden, ob die Signatur aktuell ist. Je kleiner also das Zeitfenster der gültigen Signatur nach der Antwort ist, desto höher ist die Sicherheit gegen Replay-Denial-of-Service-Angriffe.
2. SAML-Bindungssicherheit:
Die Sicherheitsaspekte beim Entwurf des SAML-Request-Response-Protokolls hängen weitgehend von der jeweils verwendeten Protokollbindung (wie in der SAML-Bindungsspezifikation [SAMLBind] definiert) ab. Die vom OASIS Security Services Technical Committee genehmigten Bindungen sind die SOAP-Bindung, die Reverse SOAP-Bindung (PAOS), die HTTP-Redirect-Bindung, die HTTP-Redirect/POST-Bindung und die HTTP-Artefakt-Bindung sowie SAML-URI-Bindungen. miniOrange SAML SSO-Plugins unterstützen Http-Redirect- und Http-POST-Bindungen.
2.1 HTTP-Redirect-Bindung
2.1.2 Denial of Service
Bedrohung: Böswillige Weiterleitungen zu Identitätsanbieter- oder Dienstanbieterzielen.
Beschreibung: Eine gefälschte Entität könnte eine Umleitung an einen Benutzeragenten veranlassen, sodass der Benutzeragent auf eine Ressource zugreift, die Single Sign-On stört. Beispielsweise könnte ein Angreifer den Benutzeragenten auf eine Abmelderessource eines Dienstanbieters umleiten, wodurch der Prinzipal von allen bestehenden Authentifizierungssitzungen abgemeldet wird.
Gegenmaßnahmen: Der Zugriff auf Ressourcen, die Nebenwirkungen hervorrufen, wird mit einem vorübergehenden Qualifikationsmerkmal angegeben, das der aktuellen Authentifizierungssitzung entsprechen muss. Alternativ könnte ein Bestätigungsdialog zwischengeschaltet werden, der auf einem transienten Qualifizierer mit ähnlicher Semantik basiert.
2.2 HTTP-POST-Bindung
2.2.1 Gestohlene Behauptung
Bedrohung: Wenn ein Abhörer die SAML-Antwort und die enthaltenen Behauptungen des echten Benutzers kopieren kann, könnte der Abhörer einen entsprechenden POST-Text erstellen und sich am Zielstandort als Benutzer ausgeben.
Gegenmaßnahmen: Wir wahren die Vertraulichkeit, wann immer eine Antwort zwischen dem SAML-SSO-Plugin und dem Browser des Benutzers kommuniziert wird. Dies bietet Schutz davor, dass ein Lauscher die SAML-Antwort und -Behauptungen eines echten Benutzers erhält. Wenn ein Abhörer die Maßnahmen zur Wahrung der Vertraulichkeit außer Kraft setzt, stehen ihm zusätzliche Gegenmaßnahmen zur Verfügung:
● Die Websites des Identitätsanbieters und des Dienstanbieters SOLLTEN angemessene Anstrengungen unternehmen, um sicherzustellen, dass sich die Uhreinstellungen an beiden Standorten höchstens um einige Minuten unterscheiden. Es sind viele Formen von Zeitsynchronisierungsdiensten verfügbar, sowohl über das Internet als auch aus proprietären Quellen.
● Wenn ein Nicht-SSO-SAML-Profil die POST-Bindung verwendet, muss sichergestellt werden, dass der Empfänger eine rechtzeitige Betreffbestätigung durchführen kann. Zu diesem Zweck MUSS eine SAML-Authentifizierungsbestätigung für den Prinzipal in der POST-Formularantwort enthalten sein.
● Werte für die Attribute „NotBefore“ und „NotOnOrAfter“ von SSO-Behauptungen SOLLTEN den kürzestmöglichen Gültigkeitszeitraum haben, der mit einer erfolgreichen Kommunikation der Behauptung vom Identitätsanbieter zum Standort des Dienstanbieters vereinbar ist. Dies liegt typischerweise in der Größenordnung von einigen Minuten. Dadurch wird sichergestellt, dass eine gestohlene Behauptung nur innerhalb eines kurzen Zeitrahmens erfolgreich eingesetzt werden kann.
● Das miniOrange SAML SSO-Plugin überprüft die Gültigkeitsdauer aller von der Identitätsanbieter-Site erhaltenen Behauptungen und lehnt abgelaufene Behauptungen ab. Wir entscheiden uns für die Implementierung eines strengeren Gültigkeitstests für SSO-Behauptungen, indem wir beispielsweise verlangen, dass der IssueInstant- oder AuthnInstant-Attributwert der Behauptung innerhalb weniger Minuten nach dem Zeitpunkt liegt, zu dem die Behauptung auf der Website des Dienstanbieters empfangen wird.
● Wenn eine empfangene Authentifizierungserklärung Folgendes enthält: Element mit der IP-Adresse des Benutzers, kann die Website des Dienstanbieters die IP-Adresse des Browsers mit der in der Authentifizierungserklärung enthaltenen IP-Adresse vergleichen.
2.2.2 Gefälschte Behauptung
Bedrohung: Ein böswilliger Benutzer oder der Browserbenutzer könnte eine SAML-Behauptung fälschen oder ändern.
Gegenmaßnahmen: Das Browser-/POST-Profil erfordert, dass die SAML-Antwort, die SAML-Assertionen enthält, signiert wird und somit sowohl Nachrichtenintegrität als auch Authentifizierung gewährleistet. Das miniOrange SAML SSO-Plugin überprüft die Signatur und authentifiziert den Aussteller.
2.2.3 Offenlegung des Browserstatus
Bedrohung: Das Browser-/POST-Profil umfasst das Hochladen von Behauptungen vom Webbrowser auf die Website eines Dienstanbieters. Diese Informationen sind als Teil des Webbrowser-Status verfügbar und werden normalerweise in einem dauerhaften Speicher auf dem Benutzersystem völlig ungesichert gespeichert. Hier besteht die Gefahr, dass die Behauptung zu einem späteren Zeitpunkt „wiederverwendet“ wird.
Gegenmaßnahmen: Über dieses Profil kommunizierte Behauptungen müssen immer eine kurze Lebensdauer haben und sollten eine haben SAML-Behauptung Element. Von den Websites der Dienstanbieter wird erwartet, dass sie sicherstellen, dass die Behauptungen nicht wiederverwendet werden.
2.2.4 Replay
Bedrohung: Bei Replay-Angriffen handelt es sich um eine erneute Übermittlung des Formulars, um auf betrügerische Weise auf eine geschützte Ressource zuzugreifen.
Gegenmaßnahmen: Das miniOrange SAML SSO-Plugin schreibt vor, dass die übertragenen Behauptungen über die Einmalverwendungseigenschaft verfügen, um den Erfolg von Replay-Angriffen zu verhindern.
2.2.5 Änderung oder Offenlegung von Statusinformationen
Bedrohung: Manipulation oder Fälschung des Relaiszustands. Einige der Nachrichten enthalten möglicherweise eine Element, dessen Integritätsschutz vom Hersteller und optionaler Vertraulichkeitsschutz empfohlen wird. Wenn diese Praktiken nicht befolgt werden, könnte ein Angreifer unerwünschte Nebenwirkungen auslösen. Darüber hinaus könnte eine legitime Systemeinheit, wenn sie den Wert dieses Elements nicht vertraulich schützt, unbeabsichtigt Informationen dem Identitätsanbieter oder einem passiven Angreifer preisgeben.
Gegenmaßnahme: Befolgen Sie die empfohlene Vorgehensweise zum Vertraulichkeits- und Integritätsschutz der RelayState-Daten. Hinweis: Da der Wert dieses Elements von derselben Systementität sowohl erzeugt als auch verbraucht wird, können symmetrische kryptografische Grundelemente verwendet werden.
3. SAML-Profilsicherheit
Die SAML-Profilspezifikation [SAMLProf] definiert SAML-Profile, bei denen es sich um Regelsätze handelt, die beschreiben, wie SAML-Assertionen in ein Framework oder Protokoll eingebettet und daraus extrahiert werden.
3.1 Webbrowser-Single-Sign-On-Profile (SSO).
Beachten Sie, dass die Benutzerauthentifizierung auf der Quellsite ausdrücklich außerhalb des Bereichs liegt, ebenso wie Probleme im Zusammenhang mit der Authentifizierung dieser Quellsite. Der Kerngedanke besteht darin, dass die Quellsystemeinheit in der Lage sein muss, sicherzustellen, dass die authentifizierte Clientsystemeinheit, mit der sie interagiert, dieselbe ist wie die im nächsten Interaktionsschritt. Eine Möglichkeit, dies zu erreichen, besteht darin, diese ersten Schritte mithilfe von TLS als Sitzungsschicht unterhalb des Protokolls durchzuführen, das für diese erste Interaktion verwendet wird (wahrscheinlich HTTP).
3.1.1 SSO-Profil
3.1.1.1 Nachrichtenänderung
Bedrohung: Für diesen Profilsatz besteht die Möglichkeit der Änderung der Nachrichten im Stream. Einige mögliche unerwünschte Ergebnisse sind wie folgt:
● Eine Änderung des ursprünglichen Antrags kann zur Ablehnung beim SAML-Aussteller führen oder
Erstellung eines Artefakts, das auf eine andere Ressource als die angeforderte abzielt
● Eine Änderung des Artefakts kann zu einem Denial-of-Service beim SAML-Konsumenten führen.
● Eine Änderung der Behauptungen selbst während der Übertragung kann zu allen möglichen Folgen führen
von schlechten Ergebnissen (wenn sie nicht signiert sind) oder Denial of Service (wenn sie signiert sind und
der Verbraucher lehnt sie ab).
Gegenmaßnahmen: Um Nachrichtenänderungen zu vermeiden, muss der Datenverkehr über ein System transportiert werden, das die Nachrichtenintegrität von Endpunkt zu Endpunkt garantiert. Für webbrowserbasierte Profile ist die empfohlene Methode zur Gewährleistung der Nachrichtenintegrität während der Übertragung die Verwendung von HTTP über TLS/SSL mit einer Verschlüsselungssuite, die eine Datenintegritätsprüfung ermöglicht.
3.1.2 Einzelnes Abmeldeprofil
Bedrohung: Passive Angreifer können die Namenskennung eines Auftraggebers sammeln. Während der ersten Schritte kann ein passiver Angreifer das einsammeln Informationen, wenn sie in der Weiterleitung ausgegeben werden. Die Offenlegung dieser Daten stellt eine Bedrohung für die Privatsphäre dar.
Gegenmaßnahmen: Der gesamte Austausch sollte über einen sicheren Transport wie SSL oder TLS erfolgen.
Bedrohung: Ein Unsignierter könnte von einer falschen Systemeinheit eingeschleust werden und so den Dienst für den Auftraggeber verweigern. Unter der Annahme, dass die NameID abgeleitet oder abgeleitet werden kann, ist es denkbar, dass der Benutzeragent angewiesen werden könnte, eine erfundene Nachricht zu übermitteln Nachricht.
Gegenmaßnahmen: Das miniOrange SAML SSO-Plugin/Modul signiert das Nachricht. Der Identitätsanbieter kann die Identität eines Auftraggebers auch überprüfen, wenn keine signierte Anfrage vorliegt.
3.2 Namensbezeichner-Verwaltungsprofile
Bedrohung: Erlauben Sie Systemeinheiten, Informationen zu korrelieren oder Identitätsinformationen auf andere Weise unangemessen offenzulegen, was die Privatsphäre beeinträchtigt.
Gegenmaßnahmen: Der IDP muss darauf achten, bei verschiedenen Dienstanbietern für denselben Auftraggeber unterschiedliche Namenskennungen zu verwenden. Der IDP sollte die Namenskennung, die er an den Dienstanbieter zurückgibt, verschlüsseln, damit nachfolgende Interaktionen eine undurchsichtige Kennung verwenden können.
3.2.1 Attributprofile
Bedrohungen im Zusammenhang mit Bindungen, die mit Attributprofilen verknüpft sind, werden oben erläutert. Es sind keine weiteren profilspezifischen Bedrohungen bekannt.
4. Zusammenfassung
Sicherheit und Datenschutz müssen systematisch angegangen werden, wobei menschliche Probleme wie Social-Engineering-Angriffe, Richtlinienprobleme, Schlüsselverwaltung und Vertrauensverwaltung, sichere Implementierung und andere Faktoren nicht in den Geltungsbereich dieses Dokuments fallen. Sicherheitstechnische Lösungen sind mit Kosten verbunden, daher müssen Anforderungen und politische Alternativen auch als „Muss“ gesetzlicher und behördlicher Anforderungen betrachtet werden. Dieses nicht normative Dokument fasst allgemeine Sicherheitsprobleme und -ansätze sowie spezifische Bedrohungen und Gegenmaßnahmen für die sichere Verwendung von SAML-Behauptungen, -Protokollen, -Bindungen und -Profilen unter Wahrung der Privatsphäre zusammen. Normative Anforderungen werden in den normativen SAML-Spezifikationen spezifiziert.
