Interoperabilität auf Basis von WS-SecurityPolicy
Choreografie der Webservice-Security
Ohne Security lässt sich eine serviceorientierte Architektur (SOA) in geschäftskritischen Bereichen nicht nutzen. Dabei unterliegen die traditionellen Security-Themen besonderen Anforderungen, etwa die Realisierung einer End-to-End-Security. Als primäre Technik hat sich der OASIS-Standard WS-Security etabliert, der die Anwendung von Verschlüsselung, Signaturen, Security Token und Timestamps im Webservice-Umfeld spezifiziert. (Mehr dazu unter www.lanline.de/kn 31636045).
Erst die Kombination der einzelnen Security-Mechanismen sowie das nachrichtenbasierende
Zusammenspiel der Kommunikationspartner ermöglichen eine ganzheitliche Sicherheit. Aufgrund der
Vielzahl an Kombinationsmöglichkeiten ist es notwendig, dass die Partner sich im Vorfeld bezüglich
des gemeinsamen Verhaltens abstimmen. Eine Interoperabilität in Bezug auf die Webservice-Security
basiert nicht nur auf der konformen Funktionsweise der Grundmechanismen, sondern erfordert auch ein
einheitliches Verständnis über deren Kombinationsmöglichkeiten.
Security-Choreografie
Die Kommunikation in der Webservicewelt beruht vorrangig auf Nachrichten, die zwischen den
Akteuren "Client" und "Service" ausgetauscht werden. Um die Vertraulichkeit und Integrität der
Nachricht zu gewährleisten sowie die Authentifizierung des Senders und Empfängers zu ermöglichen,
sind entsprechende Sicherheitsmaßnahmen erforderlich. WS-Security bietet dazu die notwendigen
kryptografischen Security-Mechanismen wie beispielsweise Verschlüsselung, Signaturen und Security
Token.
Damit Client und Service nicht nur fachlich sondern auch sicherheitstechnisch miteinander
kommunizieren können, sind korrespondierende Security-Maßnahmen auf beiden Seiten erforderlich. Die
Beschreibung dieser Maßnahmen hinsichtlich der verwendeten Security-Mechanismen und deren
Reihenfolge in der Abarbeitung bezeichnen Fachleute als Security-Choreografie.
Der Name "Choreografie" stammt ursprünglich aus dem Griechischen und setzt sich aus den Wörten "
Choreos" (Tanz) und "Graphos" (Schritt) zusammen. Üblicherweise wird er für die Beschreibung von
Bewegungen verwendet. Auf den Security-Bereich übertragen bedeutet dies: Eine gemeinsame sichere
Kommunikation zwischen Client und Service ist erst möglich, wenn beide die gleiche Choreografie
bezüglich der Elemente (Security-Mechanismen) und deren Chronologie (Reihenfolge der Abarbeitung)
verwenden. Dabei muss die Choreografie im Vorfeld zwischen Client und Service abgestimmt sein, da
sich die Verantwortung hinsichtlich Steuerung und Kontrolle an keine zentrale Instanz übertragen
lässt (Bild 1).
Wichtig: Der Begriff "Security-Choreografie" sollte nicht mit dem W3C-Standard WS-Choreography
verwechselt werden, der sich auf eine Beschreibungssprache für den Nachrichtenfluss bei
Interaktionen zwischen Webservices im Rahmen von Geschäftsprozessen bezieht.
Bedingt durch die Heterogenität in einer SOA müssen die Security-Implementierungen
unterschiedlicher Hersteller und Plattformen interoperabel zusammenarbeiten können. Leider wird im
Rahmen von Interoperabilitätsbetrachtungen häufig vernachlässigt, dass nicht nur eine konforme
Implementierung von kryptografischen Algorithmen und eine konforme Abbildung der Daten in XML
erforderlich sind, sondern auch ein gleiches Verständnis bezüglich der Security-Choreografie.
Resultierend aus den Kombinationsmöglichkeiten der Grundmechanismen gibt es theoretisch eine
große Anzahl von Security-Choreografien. Um jedoch eine möglichst große Schnittmenge von gleichen
Choreografien der verschiedenen Security-Implementierungen zu erreichen, haben sich diverse
Choreografie-Pattern herausgebildet.
Welche Security-Choreografie letztendlich zwischen Client und Service zu verwenden ist, gibt der
Service als Dienstanbieter vor. Der Client muss sich entsprechend den Vorgaben konform verhalten.
Die notwendigen Informationen werden dem Client vom Service über die WSDL bereitgestellt. Bisher
enthielt die WSDL die funktionale Beschreibung des Service (Operationen, Nachrichten) sowie diverse
Zugriffsinformationen (Adresse, Port, Protokoll). Mit dem OASIS-Standard WS-SecurityPolicy werden
diese Angaben um die Beschreibung der Security-Anforderungen erweitert.
Primäres Ziel ist die Definition von Choreografie-Pattern, die allgemeine Wege zur sicheren
Nachrichtenübertragung beschreiben. Der Fokus liegt dabei auf den Mechanismen, die die WS-Security
bereitstellt. Die in der WS-Security fehlenden Vorgaben im Bezug auf Standard-Choreografien kommen
somit mit dem Standard WS-SecurityPolicy nachträglich hinzu.
Den folgenden Choreografie-Betrachtungen liegt das folgende Szenario zu Grunde: Der
Client-seitige Akteur besteht aus dem Benutzer "Alice" (Requester) und der Softwarekomponente "
Initiator", die im Auftrag von Alice die Kommunikation zum Service abwickelt. Die Serviceseite
verkörpert dagegen die Softwarekomponente "Recipient" sowie der Serviceanbieter "Bob Corporation"
(Relying Party). Der Initiator auf der Client-Seite sendet typischerweise die Request-Nachricht an
den Recipient. Der Recipient führt intern die entsprechende Aktion aus und antwortet mit einer
entsprechenden Response-Nachricht. Bild 2 zeigt das grundsätzliche Szenario.
Zur Veranschaulichung der einzelnen Security-Choreografien dient eine Darstellung, die einem Mix
aus Aktivitäts- und Datenflussdiagrammen entspricht. Die Darstellung untergliedert sich in die
Ebenen der Client-Aktivitäten (links), der Service-Aktivitäten (rechts) sowie in die
Nachrichtenebene (mittig) mit der Abbildung der wichtigsten Daten innerhalb der Nachricht. Bild 3
zeigt das entsprechende Darstellungsschema. In den jeweiligen Aktivitätsebenen sind die relevanten
Datenstrukturen sowie die Hauptaktivitäten einschließlich der Security-Token (Keys) dargestellt.
Den internen Datenfluss zwischen Daten und Aktivitäten symbolisiert das direkte horizontale
Aneinanderreihen der Elemente. Durch den Verzicht auf die sonst üblichen Pfeile entsteht eine sehr
kompakte Darstellungsform, die sich aufgrund der Konzentration auf das Wesentliche für den
Vergleich der verschiedenen Choreografien besonders eignet.
Die Rolle der Aktivitäten spielen die jeweils komplementären Methodenpaare Verschlüsselung und
Entschlüsselung sowie die Signaturgenerierung und -validierung. Signaturen sind bezüglich ihrer
Generierung und Validierung komplizierte Vorgänge. Die Darstellung wurde so stark vereinfacht, dass
nur die beteiligten Schlüssel und die wichtigsten zu signierenden Daten auftauchen. Beispiele für
die Pattern-Darstellung zeigt Bild 5.
Die Choreografie-Patterns bestehen aus einer Kombination verschiedener Security-Mechanismen, die
wiederum auf kryptografischen Grundalgorithmen basieren. Vor der Untersuchung einiger typischer
Choreografien sollen die zugrunde liegenden Algorithmen mit Hilfe der Pattern-Darstellung nochmals
veranschaulicht werden. Bild 4 zeigt eine Legende der benutzten Symbole.
Symmetrische Verschlüsselung: Bei einer symmetrischen Verschlüsselung benutzen Sender und
Empfänger den gleichen Schlüssel. Dieser Schlüssel ist im Vorfeld zwischen beiden Parteien
auszutauschen, was in der Regel einen zusätzlichen Aufwand verursacht und der losen Kopplung
zwischen Client und Services widerspricht. Bei einer Vielzahl von Clients hat dieses Verfahren
bezüglich der Skalierung einige Schwächen, zudem sinkt die Sicherheit mit der Anzahl der verteilten
Schüssel. Von Vorteil ist dagegen die geringe benötigte CPU-Last, sodass diese Algorithmen für die
Ver- und Entschlüsselung von großen Datenmengen optimal sind. Typische symmetrische Algorithmen
sind 3DES, AES/Rijndael, Blowfish und RC4.
Asymmetrische Verschlüsselung: Asymmetrische Verschlüsselungsverfahren basieren auf zwei
verschiedenen Schlüsseln: dem öffentlichen Schlüssel (Public Key) zum Verschlüsseln der Daten und
dem privaten Schlüssel (Private Key) zum Entschlüsseln der Daten. Dies vermeidet den Austausch
eines geheimen Schlüssels. Der öffentliche Schlüssel wird üblicherweise mittels eines
X509-Zertifikates zur Verfügung gestellt. Da der private Schlüssel immer nur im Besitz eines
bestimmten Empfängers ist (sein sollte), ergibt sich durch eine asymmetrische Verschlüsselung
automatisch die Möglichkeit einer Authentifizierung des Empfängers. Alice auf der Client-Seite ist
somit in der Lage, den Service von Bob Corp. zu authentifizieren. Als nachteilig erweist sich die
Komplexität von asymmetrischen Algorithmen und der damit verbundenen geringen Performance, sodass
diese nur für kleine Datenmengen geeignet sind. Typische asymmetrische Algorithmen wären RSA,
El-Gamal und Diffie-Hellman.
Hybrid-Verschlüsselung: Dabei handelt es sich um eine Kombination aus symmetrischen und
asymmetrischen Algorithmen. Die symmetrische Methode dient zur Verschlüsselung großer Datenmengen.
Der dazu notwendige Schlüssel wird pro Nachricht generiert und dem Empfänger wiederum verschlüsselt
zur Verfügung gestellt. Für die Verschlüsselung des symmetrischen Keys verwendet man jedoch die
asymmetrische Methode, sodass neben der zertifikatsbasierten Schlüsselverteilung auch automatisch
eine Empfängerauthentifizierung zur Verfügung steht (Bild 5).
Symmetrische Signatur: Analog der symmetrischen Verschlüsselung nutzen Sender und Empfänger auch
bei den symmetrischen Signaturen gleiche Schlüssel. Entsprechend existieren hier in puncto
Schlüsselverteilung zwischen Client und Service die gleichen Probleme. Zudem bieten die
symmetrischen Signaturen nur einen Nachweis für die Daten oder Nachrichtenintegrität und werden
häufig als Security-Klammer verwendet, um mehrere Datenblöcke miteinander zu verbinden. Eine
Authentifizierung des Senders ist jedoch nicht möglich.
Symmetrische Signatur mit asymmetrischer Verschlüsselung: Um eine aufwändige Verteilung des
symmetrischen Schlüssels zu vermeiden, wird der Schlüssel generiert und mittels einer
asymmetrischen Verschlüsselung sicher zum Empfänger transportiert. Der gleiche symmetrische
Schlüssel kann nicht nur für die Signierung der Daten zum Einsatz kommen, sondern häufig auch für
deren Verschlüsselung.
Asymmetrische Signatur: Diese basiert auf der Umkehrung des asymmetrischen
Verschlüsselungsverfahrens, indem die Daten mit dem privaten Schlüssel verschlüsselt und mit dem
öffentliche Schlüssel entschlüsselt werden. Der Algorithmus gestattet, dass der Empfänger den
Absender der Daten authentifizieren kann, was einer digitalen Unterschrift gleichkommt. Eine
Vertraulichkeit der Daten ist damit jedoch nicht gewährleistet, da jeder, der im Besitz des
öffentlichen Schlüssels ist, die Daten entschlüsseln und damit lesen kann.
Bild 5 zeigt die Choreografien für die verschiedenen Arten von Signaturen.
WS-SecurityPolicy
WS-SecurityPolicy ist Bestandteil einer umfangreichen Policy-Familie, die sich aus zahlreichen
Spezifikationen zusammensetzt. WS-Policy bietet als Grundstandard eine allgemeine erweiterbare
Sprache für die Beschreibung von Anforderungen (Assertions). Auf Grundlage dieser allgemeinen
Grammatik definiert WS-SecurityPolicy konkrete Beschreibungen für Security-Eigenschaften, die auf
den Mechanismen von WS-Security und anderen Spezifikationen wie WS-Trust und WS-SecureConversation
basieren. Komplettiert wird die Policy-Familie mit dem Standard WS-PolicyAttachment, der festlegt,
wie die einzelnen Beschreibungen in die WSDL- oder UDDI-Dokumente einzubetten sind.
Das Assertion-Modell von WS-SecurityPolicy besteht aus einzelnen Gruppen, die sich miteinander
kombinieren lassen. So bestimmen beispielsweise die Protection-Assertions, welche Teile der
Nachricht mittels Verschlüsselung oder Signatur abzusichern sind. Dagegen bestimmen die
Security-Binding-Assertions und die Supporting-Token-Assertions maßgeblich die
Security-Choreografie zwischen Client und Service. Folgende Eigenschaften lassen sich dabei
definieren:
Art der Security-Tokens, die mittels der Nachricht zur Verfügung zu stellen
sind,
Transportmechanismen für die kryptografischen Schlüssel (Keys),
erforderliche Nachrichtenelemente (zum Beispiel Timestamp zur Verhinderung
einer Replay-Attacke),
die Reihenfolge der Elemente im Security-Header der SOAP-Nachricht,
die Reihenfolge der einzelnen, abzuarbeitenden Security-Mechanismen und
zusätzliche Optionen für die einzelnen Algorithmen.
Bild 6 zeigt eine Übersicht über die Assertion-Struktur von WS-SecurityPolicy. Die Aufgabe der
WS-SecurityPolicy ist die Beschreibung eines sicheren Nachrichtenaustausches zwischen Client und
Service basierend auf der WS-Security. Mittels dieser Policy-Beschreibung werden durch die
jeweiligen Security-Implementierungen alle ausgehenden Nachrichten abgesichert und alle eingehenden
Nachrichten bezüglich ihrer Einhaltung der Policy überprüft.
Liegt der Fokus der WS-Security noch auf den einzelnen Grundmechanismen der Security,
konzentriert sich die WS-SecurityPolicy auf die Choreografie-Pattern, die sich aus mehreren dieser
Mechanismen zusammensetzen. Dabei ist die grundsätzliche Choreografie durch einer der folgenden
Security-Bindings-Assertions bestimmt, die jeweils für verschiedene Einsatzszenarien geeignet
sind:
Transport-Binding,
Asymmetric-Binding und
Symmetric-Binding.
Das Transport-Binding realisiert den Nachrichtenschutz durch einen sicheren Transportkanal zum
Beispiel durch die Verwendung von HTTPS. Dabei sind Verschlüsselungs- und Signaturmechanismen auf
Nachrichtenebene nicht erforderlich. Dagegen realisieren Asymmetric-Binding und Symmetric-Binding
aufgrund der Kombination der Grundmechanismen einen transportunabhängigen Nachrichtenschutz. Da die
Beschreibungssprache von WS-SecurityPolicy einem höheren Abstraktionsgrad unterliegt, sind die
einzelnen Grundmechanismen nicht mehr ohne Weiteres erkennbar. Die auf diesen zwei Binding-Arten
basierenden typischen Choreografie-Patterns werden im Weiteren detaillierter betrachtet.
Sind jeweils Client und Service im Besitz von Security-Tokens, etwa in Form von
X.509-Zertifikaten inklusive des dazugehörigen privaten Schlüssels, kann das Asymmetric-Binding zum
Einsatz kommen. Bild 7 zeigt die Choreografie für dieses Binding. Die Verschlüsselung der Daten in
der Request-Nachricht erfolgt auf der Client-Seite mit einem generierten symmetrischen Schlüssel,
der anschließend dem Service mit dem Public-Key von Bob Corp. verschlüsselt zur Verfügung gestellt
wird. Dagegen erfolgt die Signierung mit dem Private-Key von Alice. Entsprechend muss auf der
Service-Seite für die Entschlüsselung der Daten der eigene Private-Key von Bob Corp. sowie für die
Überprüfung der Signatur der Public-Key von Alice verwendet werden.
Die Behandlung der Response-Nachricht erfolgt nach demselben Prinzip, nur sind die
Schlüsselpaare hier vertauscht. Die WS-SecurityPolicy definiert für dieses Binding den
Initiator-Token (I) und den Recipient-Token (R). Charakteristisch für diese Binding-Art ist die
Möglichkeit der gegenseitigen Authentifizierung auf Basis von Zertifikaten. Daher heißt die
Choreografie in der Praxis oft "Mutual Certificate".
Beim Symmetric-Binding nutzt man nur ein X.509 Zertifikat von der Serviceseite. Bild 8 zeigt die
entsprechende Choreografie. Für die eigentliche Verschlüsselung und Signierung generiert die
Client-Seite einen symmetrischen Schlüssel, den die Request- sowie die Response-Nachricht nutzen.
Der symmetrische Schlüssel (oft auch als Session-Key bezeichnet) wird mit dem Public-Key von Bob
Corp. verschlüsselt und dem Service eingebettet in der Request-Nachricht zur Verfügung gestellt.
Die WS-SecurityPolicy definiert für diese Binding-Art einen Protection-Token (P). Als vorteilhaft
erweist sich, dass für die Response-Nachricht nur ein einfaches Handling erforderlich ist. Da in
dieser Binding-Art eine Client-Authentifizierung nicht möglich ist, heißt diese Choreografie in der
Praxis oft auch "Anonymous".
Um auch für das Symmetric-Binding eine Authentifizierung des Clients zu erhalten, erweitert man
die Grundchoreografie durch eine weitere "unterschreibende" (endorsing) Signatur. Die
Endorsing-Signatur signiert unter Verwendung des Private-Keys von Alice die bereits existierende
symmetrische Signatur. Die Serviceseite ist aufgrund der Endorsing-Signatur in der Lage, den Client
zu authentifizieren, womit auch für das Symmetric-Binding eine gegenseitige zertifikatsbasierte
Authentifizierung zur Verfügung steht. In WS-SecurityPolicy ist ist dazu ein zusätzlicher
Endorsing-Supporting-Token (ES) zu definieren. Bild 9 zeigt die entsprechende Choreografie.
Eine weitere gängige Variante, das Symmetric-Binding um eine Client-Authentifizierung zu
erweitern, ist die Verwendung eines Username-Tokens. Das Username-Token bietet die Möglichkeit, den
Client mittels Benutzer-ID und Passwort zu authentifizieren. Um die Vertraulichkeit und Integrität
dieser Benutzerinformationen zu gewährleisten, ist das Username-Token zu verschlüsseln und in die
Nachrichtensignatur aufzunehmen. Dafür ist in der WS-SecurityPolicy eine Username-Token-Assertion
innerhalb der Assertion "Signed-Supporting-Token" zu definieren.
Neben Endorsing-Signature und Username-Token existieren weitere Möglichkeiten, die
Grundchoreografie des Symmetric-Bindings mit Mechanismen für eine Client-Authentifizierung zu
erweitern. So gewinnt beispielsweise die Verwendung von SAML-basierenden Token vorwiegend in
Szenarien von föderierten Identitäten zunehmend an Bedeutung.
Fazit
Bedingt durch die Heterogenität und den hohen Grad der Verteilung von Komponenten in einer
serviceorientierten Architektur entstehen zusätzliche Anforderungen an die Standardisierung der
Security, um eine Interoperabilität zu gewährleisten. Die mit der WS-Security umsetzbaren
Sicherheitsanforderungen wie Integrität, Vertraulichkeit und Authentifizierung sind die Grundlage
für einheitliche Security-Implementierungen. Neben der konformen Implementierung der einzelnen
Security-Mechanismen ist es auch erforderlich, dass sich Standards bezüglich der
Security-Choreografie etablieren. Dabei erfordern die unterschiedlichen Konfigurationsansätze in
den jeweiligen Implementierungen ein Verständnis über die unterstützten Choreografien.
Die OASIS-Spezifikation WS-SecurityPolicy bietet nicht nur eine Sprache, um die
Security-Anforderungen des Service zu beschreiben, sondern auch allgemeine Choreografie-Patterns
inklusive zusätzlicher Optionen, an denen sich die verschiedenen Security-Implementierungen
orientieren sollten. Dabei sollte das Motto gelten: Alles was nicht mittels eines
standardbasierenden Vertrags zwischen Client und Service beschrieben werden kann, ist nicht
verwendbar. Somit würde WS-SecurityPolicy eine zentrale Regulierungsrolle einnehmen. Die von der
WS-Security adressierte Interoperabilität auf Syntaxebene würde somit um eine Interoperabilität
bezüglich der Choreografie erweitert werden.
Lesen Sie mehr zum Thema
