Zur Zeit arbeite ich in einem größeren Kundenprojekt, das Schnittstellen über das Internet nach aussen anbietet. Über diese Schnittstellen werden unter anderem externe Buchungssysteme integriert. Als Basistechnologie werden Web Services eingesetzt. Die Verbindung wird über das Internet hergestellt.
Da sensitive sprich wertvolle Daten (z.B. Zahlungsdaten) übertragen werden, ist es natürlich extrem wichtig die Vertraulichkeit der Übertragung zu gewährleisten. Zum einen möchte man verhindern, dass die Kommunikation belauscht werden kann. Zum anderen muss man sich sicher sein, dass das angebundene System wirklich das ist für das es sich ausgibt, um beispielsweise eine "Man in the middle attack":http://de.wikipedia.org/wiki/Man-In-The-Middle-Angriff zu verhindern. D. h. es muss eine gegenseitige "Authentifizierung":http://de.wikipedia.org/wiki/Authentifizierung stattfinden.
Um das zu gewährleisten bietet sich WS-Security an. WS-Security ist einer der unzähligen Web Services Standards. WS-Security bietet hierzu verschiedene Möglichkeiten an, die einem erst einmal die Entscheidung nicht einfach machen, welche man denn nun nehmen soll. In den nächsten Einträgen hier in diesem "Blog":http://www.datazoo.de/ werde ich auf die gemachten Erfahrungen und theoretischen Hintergründe eingehen.
Gerade weil es oft nicht so einfach gelingt, WS-Security ohne Anfangsprobleme einzusetzen, ist ein Verständnis der Grundlagen unverzichtbar. Wenn dann noch Java und .NET miteinander kommunizieren sollen, erhöht man den Schwierigkeitsgrad erheblich, wie sich zeigte.
Hinzu kommen Fachausdrücke wie Asymmetrisches Kryptosystem, Digitale Zertifikate, Public Key und Private Key etc., die einem den Einstieg auch nicht wirklich einfach machen. Viele Web Services laufen daher unverschlüsselt oder man setzt auf eine SSL-basierte Verschlüsselung der gesamten Verbindung (man denke einfach an https), was auch so einige Nachteile hat (doch dazu später mehr). Es ist also ein spannendes und vielschichtiges Thema.
Fortsetzung folgt ...