Sichere Webdienste

Sicherheit ist für jede verteilte Computerumgebung wichtig. Die Sicherheit wird für Webdienste jedoch aus folgenden Gründen noch wichtiger:

  1. Es wird erwartet, dass sich die Grenze der Interaktion zwischen Kommunikationspartnern vom Intranet zum Internet erweitert. Beispielsweise erwarten Unternehmen zunehmend, dass einige Transaktionen über das Internet mit ihren Handelspartnern über Webdienste durchgeführt werden. Aus Sicherheitsgründen ist die Internetkommunikation offensichtlich viel weniger geschützt als die Intranetkommunikation.
  2. Kommunikationspartner interagieren eher miteinander, ohne zuvor eine geschäftliche oder menschliche Beziehung aufzubauen. Dies bedeutet, dass alle Sicherheitsanforderungen wie Authentifizierung, Zugriffskontrolle, Nicht-Zurückweisung, Datenintegrität und Datenschutz von der zugrunde liegenden Sicherheitstechnologie berücksichtigt werden müssen.
  3. Es wird erwartet, dass immer mehr Interaktionen von Programmen zu Programmen und nicht von Menschen zu Programmen stattfinden. Daher wird erwartet, dass die Interaktion zwischen Kommunikationspartnern, die Webdienste verwenden, dynamischer und augenblicklicher ist.
  4. Da immer mehr Geschäftsfunktionen als Webdienste verfügbar gemacht werden, wird die Anzahl der Teilnehmer in einer Webdienstumgebung größer sein als in anderen Umgebungen.

Derzeit ist SSL (Secure Socket Layer) das häufigste Sicherheitsschema für die heutigen Webdienste, das normalerweise mit HTTP verwendet wird. Trotz seiner Beliebtheit weist SSL einige Einschränkungen in Bezug auf Webdienste auf. Daher sind verschiedene XML-basierte Sicherheitsinitiativen in Arbeit, um die besonderen Anforderungen von Webdiensten zu erfüllen. Dieser Artikel untersucht diese Schemata.

SSL-Einschränkungen

Erstens bietet SSL Punkt-zu-Punkt-Sicherheit, die für Webdienste nicht ausreichend ist, da wir eine End-to-End-Sicherheit benötigen, bei der mehrere Zwischenknoten zwischen den beiden Endpunkten vorhanden sein können. In einer typischen Webdienstumgebung, in der XML-basierte Geschäftsdokumente über mehrere Zwischenknoten geleitet werden, ist es für diese Zwischenknoten schwierig, auf integrierte Weise an Sicherheitsvorgängen teilzunehmen.

Zweitens sichert SSL die Kommunikation eher auf Transportebene als auf Nachrichtenebene. Infolgedessen werden Nachrichten nur während der Übertragung auf der Leitung geschützt. Beispielsweise sind vertrauliche Daten auf Ihrem Festplattenlaufwerk nur geschützt, wenn Sie eine proprietäre Verschlüsselungstechnologie anwenden.

Drittens unterstützt HTTPS in seiner aktuellen Form die Nicht-Zurückweisung nicht gut. Die Nicht-Zurückweisung ist für Business-Web-Services und für jede Geschäftstransaktion von entscheidender Bedeutung. Was ist Nicht-Ablehnung? Nichtbestätigung bedeutet, dass ein Kommunikationspartner nachweisen kann, dass die andere Partei eine bestimmte Transaktion durchgeführt hat. Wenn E-Trade beispielsweise einen Aktientransaktionsauftrag von einem seiner Kunden erhalten und die Transaktion im Auftrag dieses Kunden ausgeführt hat, möchte E-Trade sicherstellen, dass es nachweisen kann, dass es diese Transaktion abgeschlossen hat, und zwar vor einem Schiedsgericht, z Streit entsteht. Für Transaktionen auf der Basis von Webdiensten benötigen wir ein gewisses Maß an Nicht-Zurückweisung.

Schließlich bietet SSL keine elementweise Signatur und Verschlüsselung. Wenn Sie beispielsweise über ein großes XML-Bestelldokument verfügen und dennoch nur ein Kreditkartenelement signieren oder verschlüsseln möchten, erweist sich das Signieren oder Verschlüsseln nur dieses Elements mit SSL als ziemlich schwierig. Dies liegt wiederum an der Tatsache, dass SSL ein Sicherheitsschema auf Transportebene im Gegensatz zu einem Schema auf Nachrichtenebene ist.

In den letzten Jahren hat die Technologiebranche an verschiedenen XML-basierten Sicherheitsschemata gearbeitet, um umfassende und einheitliche Sicherheitsschemata für Webdienste bereitzustellen. Diese Schemata umfassen:

  • Digitale XML-Signatur
  • XML-Verschlüsselung
  • XKMS (XML Key Management Specification)
  • XACML (Extensible Access Control Markup Language)
  • SAML (Secure Assertion Markup Language)
  • WS-Sicherheit (Web Services Security)
  • ebXML-Nachrichtendienst
  • Das Liberty Alliance-Projekt

In diesem Artikel definiere ich jede dieser Sicherheitsinitiativen, warum jede wichtig ist und wie sie alle zusammenarbeiten können.

Digitale XML-Signatur

Die digitale XML-Signatur bietet wie jede andere digitale Signaturtechnologie Authentifizierung, Datenintegrität (Manipulationssicherheit) und Nicht-Zurückweisung. Von allen XML-basierten Sicherheitsinitiativen ist der Aufwand für die digitale XML-Signatur am weitesten fortgeschritten. Das W3C (World Wide Web Consortium) und die IETF (Internet Engineering Task Force) koordinieren diese Bemühungen gemeinsam. Das Projekt zielt darauf ab, eine XML-Syntax für die Darstellung digitaler Signaturen über einen beliebigen Datentyp zu entwickeln. Die XML-Spezifikation für digitale Signaturen definiert auch Verfahren zum Berechnen und Überprüfen solcher Signaturen.

Ein weiterer wichtiger Bereich, den digitale XML-Signaturen ansprechen, ist die Kanonisierung von XML-Dokumenten. Die Kanonisierung ermöglicht die Erzeugung eines identischen Nachrichtenauszugs und damit identischer digitaler Signaturen für XML-Dokumente, die syntaktisch äquivalent sind, jedoch ein unterschiedliches Erscheinungsbild aufweisen, beispielsweise aufgrund einer unterschiedlichen Anzahl von Leerzeichen in den Dokumenten.

Warum also digitale XML-Signatur? Die digitale XML-Signatur bietet eine flexible Möglichkeit zum Signieren und unterstützt verschiedene Sätze von Internet-Transaktionsmodellen. Sie können beispielsweise einzelne Elemente oder mehrere Elemente eines XML-Dokuments signieren. Das von Ihnen signierte Dokument kann ein lokales oder sogar ein entferntes Objekt sein, sofern auf diese Objekte über einen URI (Uniform Resource Identifier) ​​verwiesen werden kann. Sie können nicht nur XML-Daten, sondern auch Nicht-XML-Daten signieren. Eine Signatur kann entweder umhüllt oder umhüllt sein. Dies bedeutet, dass die Signatur entweder in ein zu signierendes Dokument eingebettet sein oder sich außerhalb des Dokuments befinden kann.

Die digitale XML-Signatur ermöglicht auch mehrere Signaturstufen für denselben Inhalt, wodurch eine flexible Signatursemantik ermöglicht wird. Zum Beispiel kann derselbe Inhalt von verschiedenen Personen semantisch signiert, cosigniert, bezeugt und notariell beglaubigt werden.

Was ist XML-Verschlüsselung?

Das W3C koordiniert auch die XML-Verschlüsselung. Ziel ist es, eine XML-Syntax für die Darstellung verschlüsselter Daten zu entwickeln und Verfahren zum Ver- und Entschlüsseln solcher Daten festzulegen. Im Gegensatz zu SSL können Sie mit XML-Verschlüsselung nur die Daten verschlüsseln, die verschlüsselt werden müssen, z. B. nur die Kreditkarteninformationen in einem XML-Bestelldokument:

 Alice Smith ... ABCD SharedKey A23B45C56 8a32gh19908 1  

XKMS

XKMS steht für die XML Key Management Specification und besteht aus zwei Teilen: XKISS (XML Key Information Service Specification) und XKRSS (XML Key Registration Service Specification). XKISS definiert ein Protokoll zum Auflösen oder Überprüfen öffentlicher Schlüssel in signierten und verschlüsselten XML-Dokumenten, während XKRSS ein Protokoll für die Registrierung, den Widerruf und die Wiederherstellung öffentlicher Schlüssel definiert. Der Schlüsselaspekt von XKMS besteht darin, dass es als Protokollspezifikation zwischen einem XKMS-Client und einem XKMS-Server dient, bei dem der XKMS-Server seinen Clients Vertrauensdienste (in Form von Webdiensten) bereitstellt, indem er verschiedene PKI-Vorgänge (Public Key Infrastructure) ausführt B. Validierung, Registrierung, Wiederherstellung und Widerruf von öffentlichen Schlüsseln im Namen der Clients.

Lassen Sie uns nun darüber sprechen, warum wir XKMS benötigen. Um es zu erklären, muss ich zuerst die PKI diskutieren. PKI erweist sich als wichtig für E-Commerce und Webdienste. Eines der Hindernisse für die breite Akzeptanz von PKI besteht jedoch darin, dass PKI-Vorgänge wie die Validierung, Registrierung, Wiederherstellung und Sperrung öffentlicher Schlüssel komplex sind und große Mengen an Computerressourcen erfordern, wodurch die Teilnahme einiger Anwendungen und kleiner Geräte wie Mobiltelefone verhindert wird PKI-basierte E-Commerce- oder Web-Services-Transaktionen.

Mit XKMS kann ein XKMS-Server diese PKI-Vorgänge ausführen. Mit anderen Worten, Anwendungen und kleine Geräte können durch Senden von XKMS-Nachrichten über SOAP (Simple Object Access Protocol) den XKMS-Server auffordern, die PKI-Vorgänge auszuführen. In dieser Hinsicht stellt der XKMS-Server seinen Clients Vertrauensdienste in Form von Webdiensten zur Verfügung.

XACML

XACML steht für Extensible Access Control Markup Language. Das Hauptziel besteht darin, die Zugriffssteuerungssprache in der XML-Syntax zu standardisieren. Eine Standard-Zugriffssteuerungssprache führt zu geringeren Kosten, da keine anwendungsspezifische Zugriffssteuerungssprache entwickelt oder die Zugriffssteuerungsrichtlinie in mehreren Sprachen geschrieben werden muss. Außerdem müssen Systemadministratoren nur eine Sprache verstehen. Mit XACML ist es auch möglich, Zugriffssteuerungsrichtlinien aus den von verschiedenen Parteien erstellten Richtlinien zu erstellen.

SAML

Als nächstes folgt die Security Assertions Markup Language (SAML) -Anstrengung (SAML), die vom technischen Ausschuss der Sicherheitsdienste der OASIS (Organisation zur Förderung strukturierter Informationen) definiert wird. Das Komitee möchte ein Standard-XML-Framework für den Austausch von Authentifizierungs- und Autorisierungsinformationen skizzieren.

Kurz gesagt, SAML ist ein XML-basiertes Framework für den Austausch von Sicherheitsinformationen. Als Rahmen befasst es sich mit drei Dingen. Zunächst werden Syntax und Semantik von XML-codierten Assertionsnachrichten definiert. Zweitens werden Anforderungs- und Antwortprotokolle zwischen anfordernden und bestätigenden Parteien für den Austausch von Sicherheitsinformationen definiert. Drittens werden Regeln für die Verwendung von Zusicherungen mit Standard-Transport- und Nachrichten-Frameworks definiert. Beispielsweise wird definiert, wie SAML-Assertionsnachrichten mithilfe von SOAP über HTTP transportiert werden können.

SAML-Anwendungsfälle

In der SAML-Spezifikation wurden drei Anwendungsfallszenarien entwickelt, um die Anforderungen und das Design zu steuern: Single Sign-On, verteilte Transaktion und Autorisierungsdienst.

Abbildung 1 zeigt, wie SAML zum Aktivieren der einmaligen Anmeldung verwendet wird.

Angenommen, ein Benutzer meldet sich bei Smith.com an und ist authentifiziert. Später greift derselbe Benutzer auf Johns.com zu. Ohne einmaliges Anmelden müsste der Benutzer normalerweise seine Benutzeridentitätsinformationen erneut bei Johns.com eingeben. Im Rahmen des SAML-Schemas kann Johns.com durch Senden einer SAML-Bestätigungsanforderungsnachricht Smith.com fragen, ob der Benutzer bereits authentifiziert wurde. Smith.com sendet dann eine SAML-Zusicherungserklärung zurück, die angibt, dass der Benutzer tatsächlich authentifiziert wurde. Sobald Johns.com die SAML-Zusicherungserklärung erhalten hat, kann der Benutzer auf seine Ressourcen zugreifen, ohne den Benutzer aufzufordern, seine Identitätsinformationen erneut einzugeben.

Abbildung 2 zeigt einen Anwendungsfall für verteilte Transaktionen.

Nehmen wir in diesem Fall an, ein Benutzer kauft ein Auto bei Cars.com. Der gleiche Benutzer beschließt dann, eine Kfz-Versicherung bei Insurance.com abzuschließen. Wenn der Benutzer jetzt zu Insurance.com geht, um eine Versicherung zu kaufen, kann das Profil des Benutzers wie Name, Adresse und Bonitätsverlauf, das Cars.com bereits gesammelt hat, an Insurance.com weitergegeben werden. In diesem Fall sendet Insurance.com eine SAML-Bestätigungsanforderung, z. B. "Benutzerprofilinformationen an mich senden", an Cars.com, und Cars.com sendet alle ihm bekannten Benutzerprofilinformationen in SAML-Bestätigungsanweisungen an Insurance.com.

Abbildung 3 zeigt einen SAML-Anwendungsfall für einen Autorisierungsdienst.

Angenommen, ein Works.com-Mitarbeiter namens Sang möchte Möbel im Wert von Millionen bei Office.com, dem bevorzugten Möbellieferanten von Works.com, bestellen. Wenn Office.com die Bestellung von Sang erhält, möchte es natürlich wissen, ob Sang berechtigt ist, die Bestellung abzuschließen, und wenn ja, welches maximale Dollarlimit er ausgeben kann. Wenn Office.com in diesem Szenario eine Bestellung von Sang erhält, sendet es eine SAML-Bestätigungsanforderungsnachricht an Works.com, die dann eine SAML-Bestätigung zurücksendet, die angibt, dass Sang tatsächlich die Möbel bestellen darf, jedoch maximal Der Betrag, den er ausgeben kann, beträgt 000.

SAML-Behauptungen

Ich habe bereits kurz auf SAML-Behauptungen eingegangen, bei denen es sich um XML-Dokumente handelt, die Sicherheitsinformationen enthalten. Formal wird eine SAML-Behauptung als Tatsachenerklärung einer Person definiert. SAML-Behauptungen enthalten eine oder mehrere von drei Arten von Aussagen zu einem Thema, die entweder ein Mensch oder eine Programmeinheit sein können. Die drei Arten von Aussagen sind:

  • Authentifizierungsanweisung
  • Attributanweisung
  • Autorisierungserklärung

Schauen wir uns nun die verschiedenen Arten von SAML-Anweisungen genauer an.

Authentifizierungsanweisung

Eine Authentifizierungsanweisung besagt im Wesentlichen, dass eine ausstellende Behörde (behauptende Partei) behauptet, dass ein Subjekt S zum Zeitpunkt T durch Ms Authentifizierungsmittel authentifiziert wurde. Wie Sie wahrscheinlich vermutet haben, wird die Authentifizierungsanweisung verwendet, um die einmalige Anmeldung zu ermöglichen.

Listing 1 zeigt ein Beispiel für eine SAML-Zusicherung, die eine Authentifizierungsanweisung enthält:

Listing 1. SAML-Zusicherung mit einer Authentifizierungsanweisung

 (Zum Zeitpunkt T) (Betreff S) //...core-25/sender-vouches