Web Services Security ( WS-Security , WSS ) ist eine Erweiterung von SOAP , um Webdienste abzusichern . Es ist Bestandteil der Webdienstspezifikationen und wurde von OASIS veröffentlicht .

Das Protokoll legt fest, wie Integrität und Vertraulichkeit von Nachrichten gewährleistet werden können und ermöglicht die Kommunikation verschiedener Sicherheitstokenformate, wie z. B. Security Assertion Markup Language (SAML), Kerberos und X.509 . Sein Hauptaugenmerk liegt auf der Verwendung von XML-Signaturen und XML-Verschlüsselung zur Gewährleistung von Ende-zu-Ende-Sicherheit.

Merkmale

WS-Security beschreibt drei Hauptmechanismen:

  • Wie man SOAP-Nachrichten signiert, um deren Integrität zu gewährleisten. Signierte Nachrichten bieten zudem Nichtabstreitbarkeit .
  • Wie man SOAP-Nachrichten verschlüsselt, um die Vertraulichkeit zu gewährleisten.
  • Wie man Sicherheitstoken anhängt, um die Identität des Absenders festzustellen.

Die Spezifikation erlaubt eine Vielzahl von Signaturformaten, Verschlüsselungsalgorithmen und mehreren Vertrauensdomänen und ist offen für verschiedene Sicherheitstokenmodelle, wie zum Beispiel:

  • X.509-Zertifikate,
  • Kerberos-Tickets,
  • Benutzer-ID/Passwort-Anmeldeinformationen,
  • SAML-Assertions und
  • benutzerdefinierte Token.

Die Tokenformate und -semantik sind in den zugehörigen Profildokumenten definiert.

WS-Security integriert Sicherheitsfunktionen in den Header einer SOAP-Nachricht und arbeitet dabei auf der Anwendungsschicht .

Diese Mechanismen allein bieten keine vollständige Sicherheitslösung für Webdienste. Vielmehr ist diese Spezifikation ein Baustein, der in Verbindung mit anderen Webdiensterweiterungen und anwendungsspezifischen Protokollen höherer Ebene verwendet werden kann, um eine Vielzahl von Sicherheitsmodellen und -technologien zu unterstützen. Generell bietet WSS allein keine Sicherheitsgarantie. Bei der Implementierung und Verwendung des Frameworks und der Syntax liegt es in der Verantwortung des Implementierers, sicherzustellen, dass das Ergebnis keine Sicherheitslücken aufweist.

Schlüsselverwaltung, Trust Bootstrapping, Föderation und die Vereinbarung über die technischen Details (Verschlüsselungsverfahren, Formate, Algorithmen) fallen nicht in den Anwendungsbereich von WS-Security.

Anwendungsfälle

End-to-End-Sicherheit

Wenn ein SOAP-Vermittler benötigt wird und dieser nicht als vertrauenswürdig eingestuft wird, müssen Nachrichten signiert und optional verschlüsselt werden. Dies kann beispielsweise bei einem Anwendungsproxy am Netzwerkrand der Fall sein, der TCP-Verbindungen (Transmission Control Protocol) beendet.

Nichtabstreitbarkeit

Eine Methode zur Beweissicherung besteht darin, Transaktionen in einem Prüfprotokoll zu protokollieren, das spezifischen Sicherheitsvorkehrungen unterliegt. Digitale Signaturen, die von WS-Security unterstützt werden, bieten einen direkteren und besser überprüfbaren Beweis für die Beweissicherung.

Alternative Transportbindungen

Obwohl fast alle SOAP-Dienste HTTP-Bindungen implementieren, könnten theoretisch auch andere Bindungen wie JMS oder SMTP verwendet werden; in diesem Fall wäre eine Ende-zu-Ende-Sicherheit erforderlich.

Reverse-Proxy/Gemeinsames Sicherheitstoken

Selbst wenn der Webdienst auf Transport Layer Security (TLS) basiert, kann es erforderlich sein, dass der Dienst den Endbenutzer kennt, falls er über einen (HTTP-)Reverse-Proxy weitergeleitet wird. Ein WSS-Header könnte verwendet werden, um das vom Reverse-Proxy bestätigte Token des Endbenutzers zu übermitteln.

Probleme

  • Bei häufigem Nachrichtenaustausch zwischen Dienstanbieter und -nutzer ist der Aufwand für XML SIG und XML ENC erheblich. Ist Ende-zu-Ende-Sicherheit erforderlich, kann ein Protokoll wie WS-SecureConversation den Aufwand reduzieren. Ist dies ausreichend, genügt die alleinige Verwendung von Verschlüsselung oder Signierung, da die Kombination beider Verfahren deutlich langsamer ist als die Summe der Einzeloperationen. Siehe Abschnitt „Leistung“ weiter unten.
  • Die Zusammenführung mehrerer XML-Schemas wie SOAP, SAML, XML ENC und XML SIG kann zu Abhängigkeiten von verschiedenen Versionen von Bibliotheksfunktionen wie Kanonisierung und Parsing führen, die auf einem Anwendungsserver schwer zu verwalten sind.
  • Wird ausschließlich die CBC-Verschlüsselung/Entschlüsselung angewendet oder erfolgt die CBC-Entschlüsselung ohne vorherige Überprüfung einer sicheren Prüfsumme ( Signatur oder MAC ), ist die Implementierung wahrscheinlich anfällig für Padding-Oracle-Angriffe . [ 1 ]

Leistung

WS-Security verursacht einen erheblichen Mehraufwand bei der SOAP-Verarbeitung aufgrund der größeren Nachrichtengröße, der XML- und kryptografischen Verarbeitung, was schnellere CPUs sowie mehr Speicher und Bandbreite erfordert.

Eine Evaluierung aus dem Jahr 2005 [ 2 ] untersuchte 25 verschiedene SOAP-Nachrichtentypen unterschiedlicher Größe und Komplexität, die von WSS4J mit WS-Security und WS-SecureConversation auf einem Pentium 4/2,8 GHz Prozessor verarbeitet wurden. Einige Ergebnisse waren:

  • Verschlüsselung war schneller als Signierung.
  • Die Kombination aus Verschlüsselung und Signierung war 2- bis 7-mal langsamer als die Signierung allein und führte zu deutlich größeren Dokumenten.
  • Je nach Art der Nachricht machte WS-SecureConversation entweder keinen Unterschied oder halbierte im besten Fall die Verarbeitungszeit.
  • Das Signieren oder Verschlüsseln eines Arrays von bis zu 100 Kilobyte dauerte weniger als 10 Millisekunden, die Durchführung der Sicherheitsoperationen für SOAP hingegen etwa 100 bis 200 Millisekunden.

Ein weiterer Vergleichsmaßstab im Jahr 2006 [ 3 ] führte zu folgendem Vergleich:

Sicherheitsmechanismus Nachrichten/Sekunde
WS-Security (X.509) XML-Signatur & -Verschlüsselung 352
WS-SecureConversation XML-Signatur & -Verschlüsselung 798
Transport Layer Security 2918

Geschichte

Webdienste basierten ursprünglich auf der zugrundeliegenden Transportsicherheit. Tatsächlich tun dies die meisten Implementierungen noch immer. Da SOAP mehrere Transportbindungen wie HTTP und SMTP ermöglicht, war ein Sicherheitsmechanismus auf SOAP-Ebene erforderlich. Die fehlende Ende-zu-Ende-Sicherheit aufgrund der Abhängigkeit von der Transportsicherheit war ein weiterer Faktor.

Das Protokoll wurde ursprünglich von IBM , Microsoft und VeriSign entwickelt . Ihre ursprüngliche Spezifikation [ 4 ] [ 5 ] wurde am 5. April 2002 veröffentlicht und durch einen Nachtrag [ 6 ] am 18. August 2002 ergänzt .

Im Jahr 2002 wurden dem OASIS WSS Technical Committee zwei Vorschläge vorgelegt: [ 7 ] Web Service Security (WS-Security) und Web Services Security Addendum. Infolgedessen wurde WS-Security veröffentlicht.

  • WS-Security 1.0 wurde am 19. April 2004 veröffentlicht.
  • Version 1.1 wurde am 17. Februar 2006 veröffentlicht.

Der von OASIS veröffentlichte Standard Version 1.0 wies einige wesentliche Unterschiede zum Standard des IBM-, Microsoft- und VeriSign-Konsortiums auf. Viele Systeme wurden nach dem vorgeschlagenen Standard entwickelt, und die Unterschiede führten zu Inkompatibilitäten mit Systemen, die nach dem OASIS-Standard entwickelt wurden.

Die Spezifikation vor OASIS wird teilweise als „WS-Security Draft 13“ [ 8 ] oder als „Web Services Security Core Specification“ bezeichnet. Diese Bezeichnungen sind jedoch nicht weit verbreitet, und es ist heutzutage tatsächlich schwierig, eindeutig zu erkennen, ob eine Anwendung oder ein Server eine Spezifikation vor oder nach OASIS verwendet. In den meisten Forenbeiträgen wird das Schlüsselwort „WSSE“ für die Version vor OASIS verwendet, da diese die Verwendung des XML-Namensraumpräfixes „wsse“ für die URL [ 9 ] (und ähnliche URLs anderer Versionen) vorschrieb.

Das Protokoll trägt offiziell die Bezeichnung WSS und wurde von einem Komitee innerhalb von Oasis-Open entwickelt.

Zugehörige Spezifikationen

Folgende Entwurfsspezifikationen sind mit WS-Security verknüpft: WS-Federation , WS-Privacy , WS-Test .

Folgende genehmigte Spezifikationen sind mit WS-Security verknüpft: WS-Policy , WS-SecureConversation , WS-Trust , ID-WSF .

Die folgenden Architekturen nutzen WS-Security: TAS3 .

Alternative

In Punkt-zu-Punkt-Situationen lassen sich Vertraulichkeit und Datenintegrität bei Webdiensten auch durch Transport Layer Security (TLS) gewährleisten, beispielsweise durch das Senden von Nachrichten über HTTPS . WS-Security hingegen befasst sich mit dem umfassenderen Problem der Wahrung der Integrität und Vertraulichkeit von Nachrichten bis zum Zeitpunkt des Versands vom Ursprungsknoten und bietet somit sogenannte Ende-zu-Ende-Sicherheit .

Die Anwendung von TLS kann den Aufwand erheblich reduzieren, da die Kodierung von Schlüsseln und Nachrichtensignaturen in XML vor dem Senden entfällt. Eine Herausforderung bei der Verwendung von TLS besteht darin, Nachrichten über einen Proxy-Server auf Anwendungsebene zu leiten , da dieser die Anfrage für das Routing einsehen muss. In diesem Fall sähe der Server die Anfrage vom Proxy und nicht vom Client. Dies ließe sich umgehen, indem der Proxy eine Kopie des Schlüssels und Zertifikats des Clients besitzt oder indem ein vom Server als vertrauenswürdig eingestuftes Signaturzertifikat verwendet wird, mit dem ein Schlüssel-/Zertifikatpaar generiert werden kann, das dem des Clients entspricht. Da der Proxy jedoch nicht direkt mit der Nachricht arbeitet, gewährleistet er keine Ende-zu-Ende-Sicherheit, sondern nur eine Punkt-zu-Punkt-Verschlüsselung.

Siehe auch

Referenzen

  1. ^ Sabarnij, Sergej. „Padding Oracle Attacks – breaking theoretical secure cryptosystems in the real world“ (PDF) . Ruhr-Universität Bochum. Archiviert vom Original (PDF) am 26. November 2013. Abgerufen am 3. Januar 2013 .
  2. ^ „Hongbin Liu, Shrideep Pallickara, Geoffrey Fox: Performance of Web Services Security“ (PDF) . Archiviert vom Original (PDF) am 24. Februar 2021. Abgerufen am 12. Januar 2010 .
  3. ^ „Francois Lascelles, Aaron Flint: WS Security Performance. Secure Conversation versus the X509 Profile“ . Archiviert vom Original am 9. Januar 2015. Abgerufen am 24. September 2014 .
  4. ^ Bob Atkinson et al.: Web Services Security (WS-Security) . msdn.microsoft.com
  5. ^ Bob Atkinson et al.: Web Services Security (WS-Security) . schemas.xmlsoap.org
  6. ^ „Giovanni Della-Libera, Phillip Hallam-Baker Maryann Hondo: Web Services Security Addendum“ (PDF) . Archiviert vom Original (PDF) am 21. Januar 2022. Abgerufen am 31. Mai 2011 .
  7. ^ OASIS Web Services Security TC
  8. ^ Sicherheit von Webdiensten: SOAP-Nachrichtensicherheit – Arbeitsentwurf 13
  9. ^ schemas.xmlsoap.org