Bundesamt für Sicherheit in der Informationstechnik

M 4.451 Aktuelle Web-Service Standards

Verantwortlich für Initiierung: Verantwortliche der einzelnen Anwendungen, Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Web-Services sind Softwareanwendungen, die über ein Netz bereitgestellt werden. Sie stellen vielfältige IT-basierte Dienste zur Verwendung durch nahezu beliebige Clients bereit.

Im Zusammenspiel komplexer IT-Landschaften spielen Web-Services zunehmend eine bedeutende Rolle. Dabei sind Sicherheitsaspekte in der Verwendung solcher Dienste von großer Relevanz.

Um eine reibungslose Integration von Web-Services in eine Service-Orientierte Architektur ( SOA ) zu gewährleisten, wurden verschiedene Standards entwickelt, die die unterschiedlichen Aspekte von Web-Services betrachten. Vor allem die Organization for the Advancement of Structured Information Standards ( OASIS ) und das World Wide Web Consortium ( WC3 ) bieten eine Vielzahl von sich ergänzenden und aufeinander aufbauenden Standards zum Thema.

Basierend auf bewährten Internet-Transportprotokollen werden neben technischen und organisatorischen Themen auch Sicherheitsaspekte in Standards abstrahiert, um den komplexen Anforderungen der Geschäftsprozessmodellierung gerecht zu werden.

Die wichtigsten Standards mit Sicherheitsbezug sind in der folgenden Grafik visualisiert und werden in den nächsten Abschnitten kurz vorgestellt. Aufgrund der Komplexität des Themas und der beständigen Weiterentwicklung der Standards kann dies nur eine Auswahl darstellen, die keinen Anspruch auf Vollständigkeit erhebt.

XML-Encryption

Abbildung: XML-Encryption ist eine Spezifikation zur Verschlüsselung von XML -Dokumenten. Sie wird vom WC3 verwaltet.

Die XML-Encryption-Spezifikation definiert verschiedene Möglichkeiten der Verschlüsselung. Es können ganze XML-Dokumente verschlüsselt werden, einzelne Elemente mit ihren Unterelementen oder der Inhalt einzelner XML -Elemente. Damit ist eine fein granulierte Verschlüsselung der XML -Daten möglich. Die verschlüsselten Daten sind wiederum XML -Dokumente oder Teile davon.

Durch die Verschlüsselung einzelner Elemente eignet sich XML -Encryption insbesondere dann, wenn mehrere nicht vertrauenswürdige Instanzen an der Nachrichtenübermittlung beteiligt sind, diese aber keine Kenntnis über die Nachrichten der anderen Empfänger haben dürfen. Das folgende Beispiel illustriert die Verschlüsselung von Kreditkartendaten innerhalb einer Nachricht:

<?xml version='1.0'?>

<PaymentInfo xmlns='http://example.org/paymentv2'>

<Name>John Smith</Name>

<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'

xmlns='http://www.w3.org/2001/04/xmlenc#'>

<CipherData>

<CipherValue>A23B45C56</CipherValue>

</CipherData>

</EncryptedData>

</PaymentInfo>

Zu verschlüsselnde Daten werden durch die Anwendung von XML -Encryption immer durch das übergeordnete Element EncyptedData ersetzt.

Neben den verschlüsselten Daten können auch Informationen zum verwendeten Verschlüsselungsalgorithmus, dem Schlüssel und zum beabsichtigten Empfänger mit eingebettet werden. Damit ist auch eine Verschlüsselung für mehrere Empfänger möglich (zum Beispiel mit asymmetrischer Verschlüsselung im Rahmen einer Public-Key-Infrastruktur).

Die Verschlüsselung kann sowohl mit symmetrischen als auch asymmetrischen Verfahren realisiert werden. Zu beachten bei der Nutzung von XML -Encryption ist, dass sichere kryptographische Algorithmen eingesetzt werden müssen. Weitere Hinweise zu kryptografischen Algorithmen und Schlüssellängen sind in der Technischen Richtlinie des BSI Kryptografische Verfahren: Empfehlungen und Schlüssellängen - Teil 2 Verwendung von TLS (TR-02102-2) und M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens enthalten.

XML Signature

XML -Signature definiert eine XML -Syntax für elektronische Signaturen. Funktionell ähnelt XML Signature dem Krypto-Standard PKCS#7, ist aber leichter erweiterbar und speziell auf XML -Dokumente zugeschnitten.

Mit XML -Signaturen können beliebige Ressourcen signiert werden. Typischerweise sind das XML-Dokumente oder Teile davon, aber es ist auch möglich, beliebige Daten zu signieren, die über eine URL adressierbar sind.

Wird eine XML -Signatur verwendet, um eine Ressource außerhalb des umgebenden XML -Dokuments zu signieren, wird sie als detached signature bezeichnet, werden Teile des umgebenden Dokuments signiert, ist das eine enveloped signature, sind die signierten Daten in der XML -Signatur enthalten, eine enveloping signature.

Da eine logische XML -Struktur je nach Umgebung unterschiedliche, gleichermaßen gültige Darstellungsformen haben kann, muss für eine zuverlässige Signierung eine standardisierte Transformation in eine kanonische Darstellung erfolgen (Canonical XML ).

Beim Einsatz von XML -Signature ist wie auch bei der Anwendung von XML -Encryption auf die Auswahl starker kryptographischer Verfahren zu achten.

XML Key Management Specification

Die XML Key Management Specification (XKMS) basiert auf SOAP, XML -Signature und XML -Encryption und erlaubt es, asymmetrische kryptografische Schlüssel auf Basis von XML über Web-Services zu validieren und zu verwalten. Damit wird eine einfache Einbindung einer PKI (Public-Key-Infrastruktur) in die SOA ermöglicht.

Mittels XML Key Registration Service Specification (X-KRSS) werden der Lebenszyklus von Schlüsseln (Registrierung, Widerruf, Neuauflage) sowie die Wiedergewinnung von zugehörigen privaten Schlüsseln beschrieben.

XML Key Information Service Specification (X-KISS) definiert den Zugriff auf die Verifizierung von öffentlichen Schlüsseln und zugehörigen Zertifikaten.

Eine vertrauenswürdige Zwischeninstanz (TrustPoint, ebenfalls ein Web-Service) verarbeitet die Anfragen der Clients und bildet die Schnittstelle zu bestehenden Public-Key-Infrastrukturen. Dabei kann ein zentrales Trust Management realisiert werden, um die jeweiligen Anforderungen an Zugriffsschutz, Teilnehmerkreis und Vertrauenswürdigkeit umzusetzen.

SAML

Die Security Assertion Markup Language (kurz SAML) ist ein XML -basiertes Datenformat zum Austausch von Authentisierungs- und Autorisierungsinformationen. Damit können sicherheitsrelevante Informationen beschrieben und transferiert werden.

Die Entwicklung erfolgte durch das OASIS-Konsortium in Hinsicht auf Sicherheitsanforderungen in verteilten IT-Umgebungen. Neben der Nutzung verschiedener Anwendungen auf der Basis einer einmaligen Benutzeranmeldung (Single Sign-On) können auch verteilte Transaktionen mit mehreren Beteiligten und Autorisierungsdienste abgebildet werden.

Eine SAML Assertion enthält eine gekapselte Sicherheitsinformation, die grob vereinfacht folgendes besagt: "Zusicherung A wurde geprüft zur Zeit t von Prüfer R bezüglich Subjekt S unter der Bedingung C." Damit können neben Authentisierungsinformationen auch Zusicherungen über Eigenschaften von Objekten übertragen werden, die bei der Prüfung von Zugriffsrechten und dem Ablauf von Transaktionen eine Rolle spielen.

SOAP

SOAP (Simple Object Access Protocol) ist ein Netzprotokoll zum Austausch strukturierter Daten zwischen Systemen und zur Interprozesskommunikation. Es baut auf bekannte Internet-Protokolle wie zum Beispiel HTTP oder SMTP auf und basiert auf der W3C-Spezifikation XML Information Set zur Repräsentation der Daten. Es ist ein industrieller Standard des World Wide Web Consortium (W3C).

SOAP stellt ein Rahmenwerk dar, das die Struktur von Nachrichten beschreibt und festlegt, wie Daten in Nachrichten einzubetten und auszulesen sind. Da keine Vorgaben für eine Semantik der Nutzdaten definiert sind, können beliebige applikationsspezifische Inhalte übertragen werden. Somit können neben XML auch andere Datenformate (wie zum Beispiel CSV) Verwendung finden.

Zwar kann mittels SOAP über beliebige Transportprotokolle kommuniziert werden, aber in der Praxis wird aufgrund der Kompatibilität mit üblichen Netzarchitekturen meist auf die Nutzung von HTTP und HTTPS zurückgegriffen.

REST

Representational State Transfer ( REST ) beschreibt ein Entwurfsparadigma für Web-Anwendungen und kann im Großen und Ganzen auf Web-Services angewendet werden. REST basiert auf einfachen Prinzipien, die beim Entwurf und der Umsetzung einer REST -konformen Web-Anwendung berücksichtigt werden müssen.

Ursprünglich wurde REST in Hinsicht auf das HTTP -Protokoll entworfen, legt jedoch keine Details für die Implementierung fest. Es werden also auch keine Protokolle oder Standards vorgeschrieben. REST kann gut mit HTTP - beziehungsweise SOAP -basierten Web-Services umgesetzt werden.

Im Zentrum der Betrachtung steht bei REST neben den Ressourcen, die eine Web-Anwendung bereitstellt, die Uniformität der Kommunikationsschnittstelle. Daneben wird eine simplifizierte Struktur der Netzkommunikation entworfen, um die Unabhängigkeit, Skalierbarkeit und Vernetzbarkeit der Komponenten zu erhöhen.

Im Einzelnen gelten folgende Prinzipien:

  • Client-Server: Die Zuständigkeiten zwischen Server und Client werden klar aufgeteilt (Separation of Concerns). Dies gilt insbesondere für die Datenhaltung.
  • Zustandslosigkeit: Die Kommunikation ist zustandslos. Jede REST -Anfrage enthält alle Informationen, die der Server benötigt, um die Anfrage ordnungsgemäß zu verarbeiten. Der Server muss keine Client-bezogenen Informationen aus Kommunikationsvorgängen speichern, um zukünftige Anfragen zu bearbeiten.
  • Cachefähigkeit: Ressourcen können vom Server als cachefähig gekennzeichnet werden. Damit können alle Stationen der Netzkommunikation bis hin zum Client die Serverantwort zwischenspeichern und für Interaktionen wiederverwenden.
  • Einheitliche Schnittstelle: Auf die Schnittstelle zwischen Client und Server wird das aus der Softwareentwicklung bekannte Prinzips der Generalisierung angewendet. Dadurch wird die Standardisierung von Adressierung, Kommunikation, Datenstrukturen und Transaktionen verpflichtend für eine REST -konforme Web-Anwendung.
  • Mehrschichtigkeit: Durch die Einführung einer geschichteten Web-Architektur wird die Skalierbarkeit und Flexibilität weiter erhöht. Dabei kennt jede Komponente nur ihre unmittelbaren Kommunikationspartner und hat keine Informationen über die weitere Struktur des Gesamtsystems. Zudem können durch Zwischenschichten und Proxys auch Dienste gekapselt, Altsysteme eingebunden, Sicherheitsanforderungen umgesetzt und Aufgaben und Lasten verteilt werden.
  • Code on Demand: Dem Server wird ermöglicht, den Clients Softwarebestandteile zur Verfügung zu stellen, mit denen die clientseitige Funktionalität erweitert werden kann. Damit werden dem Client serverunabhängige Aktivitäten auf der Basis der übermittelten Daten ermöglicht.

Das für die Standardisierung der Schnittstelle relevante Prinzip der einheitlichen Schnittstelle enthält folgende Vorgaben:

  • Adressierung: Bereitgestellte Ressourcen müssen eindeutig identifizierbar sein. Dafür bieten sich URIs (Uniform Resource Identifier) oder URLs (Uniform Resource Locator) an.
  • Manipulation von Ressourcen über Repräsentationen: Aktionen über Ressourcen (Anlegen, Abrufen, Ändern, Löschen) werden durch den Austausch von Repräsentationen der Ressourcen durchgeführt. Dabei können die gewünschten Daten in verschiedenen Darstellungsformen (Media Type) transferiert werden (zum Beispiel HTML, XML , JSON, PDF). Die gewünschte Aktion wird über Operationen wie zum Beispiel POST (Erzeugen von Ressourcen), GET (Abrufen von Ressourcen), PUT (Aktualisieren von Ressourcen), DELETE (Löschen von Ressourcen) festgelegt. Weitere Operationen zu Status, Zugriffsrechten, Historie der Ressource oder anderen Funktionen sind möglich.
  • Selbstbeschreibende Nachrichten: Jede Anfrage eines Clients und jede Serverantwort ist eine Nachricht und muss selbstbeschreibend sein, das heißt die Nachricht enthält alle Informationen, die der Empfänger benötigt, um seine Aufgabe ordnungsgemäß durchzuführen.
  • Verwendung von Hypermedia: Hypermedia ist der Antrieb einer Web-Anwendung. Jede Manipulation des Anwendungszustandes und jeder Ressourcenabruf erfolgt über Hypermedia. Hypermedia bedeutet in diesem Zusammenhang, dass alle für den Client relevanten Web-Service-internen Verweise auf andere Repräsentationen der Ressourcen sowie alle angebotenen Aktivitäten durch den Web-Service selbst zur Verfügung gestellt werden müssen, der Client also keine umfassende Kenntnis der Web-Service-Struktur benötigt, um diesen nutzen zu können. Die Bereitstellung dieser Informationen kann zum Beispiel als in eine XML-Struktur eingebundene URL erfolgen.

Folgende Vorteile ergeben sich aus der Anwendung von REST für Web-Services:

Durch die strikte Aufgabenteilung können Client und Server leichtgewichtig ausgelegt sein, ein hoher Grad an Interoperabilität wird ermöglicht, und alle Komponenten können unabhängig voneinander weiterentwickelt oder sogar ausgetauscht werden. Die Zustandslosigkeit der Kommunikation vereinfacht die beidseitige Datenhaltung. Hypermedia ermöglicht die Nutzung von Web-Services ohne genaue Kenntnis der zugrunde liegenden Implementierung und erleichtert die Orchestrierung einer SOA-Landschaft. Die Einheitlichkeit der Schnittstellen erfordert ein hohes Maß an Standardisierung, die Voraussetzung für eine systemübergreifende SOA -Integration ist. Die Mehrschichtigkeit erlaubt eine transparente Kommunikation auch in komplexen Systemlandschaften mit hohen Anforderungen an Verfügbarkeit.

Web Services Description Language (WSDL)

WSDL ist eine XML -basierte Metasprache zur Beschreibung von XML -basierten Webservices. Eine WSDL-Datei stellt eine maschinenlesbare Beschreibung der Aufrufe, Parameter, Datenstrukturen und Rückgabewerte eines Web-Service dar. Es sind neben der Schnittstellenbeschreibung und den Zugangsprotokollen alle notwendigen Informationen für den Zugriff auf den Web-Service enthalten.

WSDL wird häufig mit SOAP und XML Schema eingesetzt, um XML -basierte Web-Services in einer verteilten IT-Landschaft zu orchestrieren. Ein Client kann aus der WSDL-Datei ermitteln, welche Funktionen auf dem Server verfügbar sind. Aus der WSDL-Spezifikation des Dienstes kann automatisiert Quellcode für die Verwendung des Web-Service mittels SOAP -Nachrichten generiert werden.

UDDI (Universal Description, Discovery and Integration)

UDDI bezeichnet im SOA-Umfeld einen standardisierten Verzeichnisdienst für Web-Services. Er spielt eine zentrale Rolle bei der dynamischen Bindung von Clientanforderungen an Web-Services.

Die benötigten Informationen werden in drei Katalogen angeboten. In den White Pages werden die Basisinformationen vorgehalten, sie beschreiben die Identität des Serviceanbieters. Die Yellow Pages kategorisieren die angebotenen Dienste nach einer standardisierten Taxonomie. Dabei können international anerkannte Standards zum Einsatz kommen (zum Beispiel UNSPSC - United Nations Standard Products and Services Code). Die Green Pages schließlich halten die Schnittstellenbeschreibungen der Web-Services vor.

Die technischen Aspekte des Dienstes werden strukturiert im sogenannten tModel abgelegt. Um eine Anforderung einem konkreten Dienst zuzuordnen, werden die tModel-Beschreibungen (tModel-Keys) von Client und Web-Service miteinander abgeglichen. Die Binding-Informationen (bindingTemplate) werden dann dem Client dynamisch hinzugefügt.

WS-*

Eine eigene Gruppe industrieller Standards sind die WS-*-Spezifikationen. Sie werden überwiegend vom W3C und OASIS betreut und schließen die Lücke zwischen den eher technisch ausgerichteten Web-Service-Standards und den hohen Anforderungen der Geschäftsprozess-Ebene. Sie richten sich an jeweils genau ein Anwendungsgebiet, bauen teilweise aufeinander auf, und können kombiniert werden, um komplexe Anforderungen abzubilden. Dazu gehören neben Adressierung, Kontext, Koordination, Zuverlässigkeit, Metadaten und Transaktion insbesondere auch Vertraulichkeit, Integrität und Verfügbarkeit, aber auch Zugriffssteuerung und Rechtemanagement.

Die Standardisierung ermöglicht die plattformunabhängige und systemübergreifende Abbildung komplexer Geschäftsprozesse auf der Basis von SOAP und WSDL. Es folgt eine Auswahl von WS-*-Spezifikationen mit besonderer Relevanz für die Sicherheit von Web-Services.

WS-Policy

WS-Policy ist ein Standard, der es Web-Services erlaubt, Auskunft über ihre Richtlinien bezüglich Sicherheit, Qualität oder andere Anforderungen zu geben. Es ist die grundlegende Spezifikation für ein Rahmenwerk, das die Definition erforderlicher und optionaler Richtlinien für Dienste und Dienstnutzer ermöglicht.

Mittels WS-PolicyAssertions wird eine Menge an Standardzusicherungen beschrieben, die innerhalb einer Policy verwendet werden können. Eine Policy Assertion beschreibt eine Verhaltenseigenschaft, eine Pflicht oder eine Möglichkeit. Eine Menge dieser Richtlinien kann in der WSDL einer Web-Service-Entität (Operation, Nachricht, Endpunkt) zugeschrieben werden. In der WS-Policy-Spezifikation wird nicht festgelegt, welche Richtlinien existieren, das geschieht in speziellen Domänen-spezifischen Spezifikationen (Sicherheit, Transaktion und andere).

WS-PolicyAttachment standardisiert das Verknüpfen von Policies mit WSDL und UDDI, wahlweise innerhalb der Beschreibungselemente oder extern und referenzierbar.

WS-Security

Die Web Services Security Language (WS-Security, WSS) basiert auf XML -Signature und XML -Encryption. Ziel vom WS-Security ist es, den sicheren Austausch von SOAP -Nachichten zu gewährleisten und somit die Vertraulichkeit und Integrität von Nachrichten sicherzustellen. Als Erweiterung für SOAP schreibt sie genau vor, auf welche Weise Verschlüsselungsinformationen, Signaturen und Authentisierungstoken in Nachrichten eingebettet werden. Dabei werden verschiedene Modelle von Authentisierungstoken unterstützt, unter anderem X.509-Zertifikate, Kerberos-Tickets, Benutzername/Password-Kombinationen und SAML-Assertions. Die Nachricht ist somit durchgehend geschützt, wenn die Übertragung durch mehrere Instanzen erfolgt.

Ein einfaches Authentisierungstoken für eine Authentisierung mit Benutzername und Passwort sieht bei WS-Security zum Beispiel so aus:

<wsse:UsernameToken>

<wsse:Username>manfred.testheimer</wsse:Username>

<wsse:Password Type="wsse:PasswordDigest">

59xi0qBCwKxwgmMxU38nOouyqDA=

</wsse:Password>

<wsse:Nonce>Sd7rTLv5W/mLa9eX2a0+rk==</wsse:Nonce>

<wsu:Created xmlns:wsu=

"http://schemas.xmlsoap.org/ws/2002/07/utility">

2013-07-12T14:12:45Z

</wsu:Created>

</wsse:UsernameToken>

Die Zufallszahl (Nonce) und der Generierungszeitpunkt, die beide in den Password-Hash eingehen, sind optional. Von diesen Möglichkeiten sollte Gebrauch gemacht werden, da damit die Robustheit gegen Angriffe erhöht wird.

Ein Kerberos-Ticket sieht in WS-Security dagegen zum Beispiel so aus:

<wsse:BinarySecurityToken

ValueType="wsse:Kerberosv5ST"

EncodingType="wsse:Base64Binary">

SGllciBrb2VubnRlIElocmUgV2VyYnVuZyBzdGVoZW4hCg==

</wsse:BinarySecurityToken>

WS-Transfer

WS-Transfer ist die Spezifikation eines SOAP-basierten Protokolls für den Austausch von XML -basierten Repräsentationen von Entitäten über eine Web-Service-Infrastruktur. Entitäten sind dabei:

  • Ressourcen, die über einen Web-Service adressierbar sind und eine XML -Repräsentation haben
  • Web-Services, die entsprechend einer XML-Repräsentation neue Ressourcen generieren (Resource Factories)

Dabei werden Anfrage und Antwort zu einer Transaktion jeweils als XML -Dokumente übertragen. Eine direkte Einbettung der XML-Repräsentation ist möglich.

Als Operationen für Ressourcen sind GET (verpflichtend) sowie PUT und DELETE (jeweils optional) vorgeschrieben. Für Resource Factories ist die Operation CREATE (optional) vorgesehen.

WS-MetaDataExchange

Web-Services benutzen Metadaten, um zu beschreiben, auf welche Art andere Endpunkte auf sie zugreifen können, und was dabei zu beachten ist. Dazu werden vor allem XML -Schema, WSDL, WS-Policy und WS-PolicyAttachment verwendet. Um den automatisierten Zugriff auf diese Metadaten zu erleichtern, definiert WS-MetaDataExchange Metadata Resources, die Consumern erlauben, die für eine korrekte Nutzung der Web-Services erforderlichen Metadaten abrufen zu können. Dafür werden Ressourcen nach dem WS-Transfer-Standard verwendet, die die entsprechenden Informationen in XML verpackt enthalten.

WS-Agreement

In einer SOA-Landschaft sind Aussagen über Verfügbarkeit, Qualität und andere Eigenschaften von Web-Services von entscheidender Bedeutung für die Konsumenten. WS-Agreement beschreibt Protokolle und Datenstrukturen zur Repräsentation von Service Level Agreements für Web-Services.

Unter anderem können Übereinkünfte angeboten, akzeptiert, abgelehnt oder terminiert werden, und der Status einer Übereinkunft kann abgefragt werden.

Großer Wert wurde auf Flexibilität und Erweiterbarkeit gelegt, um die domänenspezifischen Anforderungen in unterschiedlichen Umgebungen abbilden zu können.

WS-ReliableMessaging

WS-ReliableMessaging widmet sich der zuverlässigen Nachrichtenübermittlung. Damit kann sichergestellt werden, dass Nachrichten auch im Falle eines Versagens einzelner Komponenten verlässlich den Empfänger erreichen. Damit kann die Anwendung einerseits auf Fehler oder Probleme in der Kommunikation reagieren, andererseits kann für die übermittelten Nachrichten nachgewiesen werden, dass sie den Empfänger erreicht haben (Schutzziel der Nichtabstreitbarkeit).

Das wird erreicht, indem zwischen Sender und Empfänger eine Vermittlerschicht eingezogen wird, die von den Kommunikationsteilnehmern praktisch transparent genutzt wird. Die Nachricht wird über die Reliable Messaging Source an die Zwischenschicht übergeben, durch entsprechende Mechanismen abgesichert zugestellt und von der Reliable Messaging Destination dem eigentlichen Empfänger übergeben. Die Kommunikation basiert auf SOAP und WSDL. An die Übermittlung können unterschiedliche Anforderungen gestellt werden: AtLeastOnce (mindestens einmal), AtMostOnce (höchstens einmal), ExactlyOnce (genau einmal) sowie, kombinierbar mit jedem der anderen, InOrder (in der ursprünglichen Reihenfolge). Wenn die geforderte Übermittlung nicht möglich ist, wird dem Absender ein Fehler gemeldet.

Zu WS-ReliableMessaging gehört auch WS-Reliable Messaging Policy Assertion, womit sich Richtlinien rund um die verlässliche Nachrichtenübermittlung beschreiben lassen, die in WS-Policy eingebunden werden können.

WS-Transaction

WS-Transaction ist ein Standard, der das aus der Datenbankwelt bekannte Konzept der Transaktion für Web-Services bereitstellt. Ziel ist, bei Operationen in komplexen Umgebungen gemeinsame Aktivitäten zu koordinieren und ein transparentes und konsistentes Verhalten aller beteiligten Dienste zu gewährleisten.

Dafür werden drei Unterspezifikationen bereitgestellt: WS-Coordination zur Koordinierung von Aktivitäten, WS-AtomicTransaction für kurz laufende Transaktionen und WS-BusinessActivity für länger laufende Transaktionen.

WS-Coordination

WS-Coordination bietet einen erweiterbaren Rahmen, der Protokolle beschreibt, die die Koordinierung von Web-Service-Aktivitäten in verteilten Systemen erlauben. Damit kann zwischen mehreren Beteiligten eine Übereinkunft hergestellt werden, wie das Ergebnis ihrer aus einzelnen Aktivitäten bestehenden Transaktion aussehen soll. Es stellt auch eine Abstraktionsmöglichkeit für bestehende Koordinationssysteme wie zum Beispiel Arbeitsabläufe (Workflows) dar.

Eine zentrale Stelle (Coordination Service) übernimmt die Koordination und erlaubt die Registrierung der Teilnehmer innerhalb eines Koordinationskontextes.

WS-AtomicTransaction

WS-AtomicTransaction basiert auf WS-Coordination und spezifiziert nur noch die Protokolle für kurz laufende Transaktionen, für die die ACID-Eigenschaften wichtig sind: Atomicity (Abgeschlossenheit), Consistency (Konsistenzerhaltung), Isolation (Isolation), Durability (Dauerhaftigkeit).

Dafür werden folgende Protokolle vorgesehen: Completion (für den Initiator der Transaktion), Volatile Two-Phase Commit (für Teilnehmer mit flüchtigen Ressourcen wie zum Beispiel Caches) und Durable Two-Phase Commit (für Teilnehmer mit nicht flüchtigen Ressourcen wie zum Beispiel Datenbanken).

Eine Atomic Transaction kann nur erfolgreich beendet werden, wenn alle Teilaufgaben erfolgreich beendet wurden. Da vorausgesetzt wird, dass sich alle Teilnehmer kooperativ verhalten, sollten Atomic Transactions nur in einem vertrauenswürdigen Umfeld eingesetzt werden.

WS-BusinessActivity

WS-BusinessActivity basiert ebenfalls auf WS-Coordination und definiert den Koordinationstyp Business Activity. Dieser Koordinationstyp ist für den Einsatz bei langlebigen Aktivitäten mit Teilnehmern unterschiedlicher Vertrauenswürdigkeit (Trust Domains) gedacht.

Eine Business Activity erlaubt den Teilnehmern die wechselseitige Übereinkunft bezüglich verteilt auszuführender Operationen. Ein wesentliches Merkmal ist, dass Operationen beliebig verschachtelt werden können (Nested Scopes). Dabei kann auch auf Atomic Transactions zurückgegriffen werden.

Im Unterschied zur Atomic Transaction kann eine Business Activity auch dann erfolgreich beendet werden, wenn einzelne, untergeordnete Aktivitäten scheitern. Die Entscheidung darüber ist vom Initiator der Aktivität zu treffen. Damit sind auch komplexe Geschäftsprozesse und Entscheidungsabläufe abbildbar, und es können Teilnehmer unterschiedlicher Kooperationsfähigkeit eingebunden werden.

WS-Trust

WS-Trust ist eine Erweiterung von WS-Security und ermöglicht den Austausch von zugesicherten Eigenschaften bestimmter Subjekte innerhalb und zwischen Domänen (Trust Domänen). Dabei geht es um das Herausgeben, Erneuern und Validieren von Security Tokens sowie die Vermittlung, den Aufbau und die Bewertung eines sicheren Nachrichtenaustauschs.

WS-Trust umfasst die Beschreibung eines Web-Service, der mit WS-Security kompatible Security Tokens herausgibt (Security Token Services, STS). Zudem wird das Format von Nachrichten festgelegt, die für die Kommunikation rund um Security Tokens Verwendung finden, sowie Mechanismen zum Austausch kryptografischer Schlüssel.

WS-SecureConversation

WS-SecureConversation verfolgt den Ansatz einer sitzungsbasierten Sicherheit. Somit unterstützt WS-SecureConversation einen Sicherheitskontext, der nach der ersten Authentisierung generiert wird. Der Sicherheitskontext erlaubt eine fortdauernde abgesicherte Kommunikation über mehrere Nachrichten oder Transaktionen hinweg und senkt damit den Aufwand für die Absicherung der Kommunikation. Dieser Standard sollte insbesondere dann angewendet werden, wenn eine hohe Anzahl an Nachrichten zwischen Web-Services ausgetauscht werden muss.

Der durch WS-Secure-Conversation generierte Sicherheitskontext besteht aus einem gemeinsamen Sitzungsschlüssel, der auch als SecurityContextToken-Element bezeichnet wird. Der Austausch des Tokens zwischen den Parteien erfolgt durch das Diffie-Hellmann-Verfahren und wird dann für die Ver- und Entschlüsselung verwendet. Zur Generierung des Sicherheitskontextes stehen die folgenden Möglichkeiten bereit:

  • Nutzung eines Security Token Services (STS) mit WS-Trust: Die Kommunikationspartner vertrauen einem externen Dienst, der für das Erzeugen der Token verantwortlich ist.
  • Erzeugung und Verteilung durch einen Kommunikationspartner: Ein Kommunikationspartner ist für das Erzeugen und Verteilen des Tokens verantwortlich. Das setzt voraus, dass alle Beteiligten dem Aussteller vertrauen.
  • Erzeugung mit einem Challenge/Response-Verfahren.

Zusätzlich existieren Mechanismen, um einen Sicherheitskontext zu erneuern, abzuändern, zu erweitern oder aufzukündigen.

WS-Federation

WS-Federation steht in engem Zusammenhang mit WS-Security und beschreibt eine flexible Infrastruktur für föderierte Identitäten. Bei diesem Konzept werden Identitäten nicht von einer zentralen Instanz verwaltet, sondern von verteilten Instanzen, die jeweils für eine bestimmte Gruppe von Identitäten zuständig sind (zum Beispiel Für die Mitarbeiter einer Institution). Die einzelnen Instanzen zur Identitätsverwaltung sind miteinander verbunden und vertrauen sich gegenseitig. WS-Federation erlaubt die Vermittlung von Identitäten, Attributen und Authentisierungsvorgängen zwischen unterschiedlichen Sicherheitskontexten. Dabei wird auf WS-Trust und WS-MetadataExchange zurückgegriffen.

WS-SecurityPolicy

Web Service Security Policy Language (WS-SecurityPolicy) beschreibt sicherheitsbasierte Policy Assertions. Damit sind spezielle Zusicherungen gemeint, die Web-Services erfüllen müssen, damit sicherheitsrelevante Aspekte erfüllt sind.

Die Spezifikation erweitert die fundamentalen Sicherheitsprotokolle, die in WS-Security, WS-Trust und WS-SecureConversation spezifiziert sind, indem Mechanismen angeboten werden, die Anforderungen und Fähigkeiten von Web-Services als Zusicherungen (Policies) darzustellen.

Web Single Sign-On

Web Single Sign-On Interoperability Profile und Web Single Sign-On Metadata Exchange Protocol sind Spezifikationen zum Identitätsmanagement, die die Interoperabilität mit Protokollen der WS-Federation und der Liberty Alliance sicherstellen sollen. Sie basieren unter anderem auf SAML und WS-MetadataExchange.

Ziel ist es, das Identitätsmanagement bestehender Lösungen in Web-Services zu integrieren und den Zugriff auf Eigenschaften der hinterlegten Identitäten zu ermöglichen. Damit ist eine plattformübergreifende, zentralisierte Identitätsverwaltung möglich, die eine Zugriffssteuerung für Web-Services mit einbezieht.

WS-BPEL

Die Web Services Business Process Execution Language (WS-BPEL) ist eine Sprachdefinition zur Spezifizierung von Web-Service-Aktivitäten innerhalb von Geschäftsprozessen. Sie wird zur Beschreibung der Orchestrierung von Webservices verwendet und basiert auf WSDL. Die Beschreibung selbst wird wiederum als Web-Service bereitgestellt.

Neben Basic Activities (grundlegende Aktivitäten) und Structured Activities (komplexe Abläufe von Aktivitäten) sind auch Scopes (gebündelte Aktivitäten) vorgesehen, die auch eine Fehlerbehandlung, eine Ereignisbehandlung, eine Terminationsbehandlung sowie eine Kompensationsbehandlung erlauben. Damit werden auch langandauernde Transaktionen ermöglicht.

Durch funktionale Aufspaltung und die Komposition von Web-Services ist ein hohes Maß an Flexibilität gewährleistet.

Mit den Erweiterungen WS-BPEL4People und WS-HumanTask lässt sich auch menschliche Interaktion in Geschäftsprozessen adressieren.

WS-CDL

Web Services Choreography Description Language (WS-CDL oder auch WS-Choreography) wird zur Choreografie von Web-Services eingesetzt. Die XML-basierte Sprache beschreibt die unmittelbare Kommunikation zwischen Web-Service-Akteuren aus der Beobachterperspektive, indem das Verhalten der Akteure definiert wird.

Dabei werden mit der Kommunikationsstruktur die nicht-funktionalen Eigenschaften eines Web-Service beschrieben. Das Ziel ist, ein globales Szenario zu beschreiben, dem die Akteure in ihrem Verhalten folgen, das aber keine zentrale Kontrollinstanz kennt.

Eine Choreografie definiert wiederverwendbare allgemeine Regeln, die den Nachrichtenaustausch zwischen Akteuren steuern, und die möglichen Muster kollaborativen Verhaltens, die zwischen zwei oder mehr zusammenwirkenden Teilnehmern vereinbart sind. Die Wiederverwendbarkeit der Vorschriften erlaubt die vereinfachte Komposition auch komplexer Choreografien.

OSCI

Online Services Computer Interface ( OSCI ) ist eine Protokollspezifikation für die öffentliche Verwaltung in Deutschland. Sie basiert auf bereits bestehenden Standards wie zum Beispiel den Sicherheitsstandards für XML ( XML -Encryption und XML Signature), SOAP , SAML und einigen WS-*-Standards. Für die Anforderungen der öffentlichen Verwaltung wurden spezielle Erweiterungen definiert. Ziel ist die sichere, vertrauliche und rechtsverbindliche Übertragung elektronischer Daten über das Internet. Das Protokoll wird vom Bundesministerium des Inneren als obligatorischer Standard für elektronische Transaktionen mit der Bundesverwaltung gesetzt und ist die Basis für viele weitere Spezifikationen für XML in der öffentlichen Verwaltung (XÖV), zum Beispiel zur elektronischen Datenübermittlung im Meldewesen.

Außerhalb von E-Government-Anwendungen der öffentlichen Verwaltung hat OSCI praktisch keine Bedeutung.

Als wesentliche Anforderungen an die Kommunikation wurden fünf Sicherheitsaspekte identifiziert und umgesetzt: Authentizität, Integrität und Vertraulichkeit sowie Nichtabstreitbarkeit und Zurechenbarkeit. Dabei wurden auch Erfordernisse nach dem Signaturgesetz berücksichtigt. So ist es möglich, zwischen fortgeschrittener und qualifizierter elektronischer Signatur mit und ohne Anbieterakkreditierung gemäß Signaturgesetz zu wählen.

Mit der Version 2 des Standards wurde besonderes Gewicht auf die Anforderungen bei der Verwendung mit Web-Services gelegt. Die Erweiterung berücksichtigte dementsprechend vor allem international anerkannte WS-Standards.

Stand: 14. EL Stand 2014

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK