Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Java EE 7: Web Services

Absichern einer Web-Service-Methode

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
JAX-WS definiert SOAPHandler, das sind Klassen, mit denen sich SOAP-Nachrichten sowohl auf Ebene eines Clients, als auch auf Serverebene manipulieren bzw. analysieren lassen.

Transkript

JAX-WS kennt das Konzept der SOAPHandler. SOAPHandler sind Komponenten, die zusätzlich zum eigentlichen Webdienst oder Webdienst-Client genutzt werden können, um SOAP-Nachrichten zu analysieren, zu manipulieren und gegebenenfalls zu korrigieren. Wir verwenden SOAPHandler in diesem Video, um eine Authentifizierungslösung umzusetzen. Und zwar auf Ebene des Web-Services-Client und des Web Services selbst. Dieser Ansatz, SOAPHandler für die applikationsbasierte Sicherheit zu verwenden, erlaubt es uns, die Applikationen so zu gestalten, dass sie selbst für ihre Sicherheit zuständig ist. Das bedeutet, wir benötigen keine externen Komponenten und letztlich noch nicht einmal eine Abhängigkeit auf den Application Server, in dem die Applikation selber läuft. Sondern wir können das selber nach Bedarf im Code implementieren. Auf der anderen Seite bedeutet dies allerdings auch, dass normalerweise jeder Aufruf an den Web Service tatsächlich auch beim Web Service ankommt. Denn der Application Server ist ja nun außen vor. Allerdings lässt es sich auch sehr wohl mit der containerbasierten Authentifizierung kombinieren. Das bedeutet, dass sich der Web-Service-Client zunächst einmal in irgendeiner Form am Server authentifizieren kann, bevor er auf den Service zugreifen kann. Dieser generelle Ansatz, SOAPHandler zu benutzen, erlaubt es uns, eigene Implementierungen, nicht nur für Sicherheit, sondern zum Beispiel auch für Logging oder sonstiges bereitzustellen. Meistens werden für sicherheitstechnische Implementierungen SOAPHeader-Werte benutzt. Zu diesem Zweck wird der Header meistens um ein bis zwei Felder erweitert. Dies geschieht auf Client-Seite. Auf der Server-Seite werden dann die Header-Werte ausgewertet. Sollten sie nicht vorhanden sein oder sind sie fehlerhaft, wird eine entsprechende Exception generiert und der Client wird darüber informiert. Das Ganze basiert darauf, dass so ein SOAP-Dokument nicht nur monolithisch aufgebaut ist, sondern es gibt außenrum ein Envelope-Element und innerhalb dieses Envelopes befinden sich dann ein Buddy-Element, über das die eigentlichen Daten transportiert werden, und ein optionales Header-Element, und ein optionales Fault-Element, was Fehler anzeigt. In aller Regel werden dann Client und Server über eine SOAPHandler- Implementierung verfügen, die in unserem Fall eine Authentifizierung umsetzen wird. Um das Ganze tatsächlich zu programmieren, werden wir nun ins Eclipse wechseln und uns dort zunächst dem Client widmen. Auf Ebene des Client-Projekts lege ich jetzt eine neue Klasse an. So ein SOAPHandler ist eine ganz normale Java-Klasse. Sie befindet sich in einem eigenständigen Package. Sie muss das nicht zwingend, aber das macht alles um einiges sauberer und besserer wartbar. Wie gesagt, es ist eine ganz normale Klasse. Wir nennen sie AuthenticationClientHandler. Diese Klasse implementiert das Interface SOAPHandler vom Typ SOAPMessageContext. Achten Sie darauf, dass Sie die Klasse SOAPMessageKontext auch korrekt refefenzieren. Das Interface definiert vier Methoden, von denen uns aber nur eine interessiert. Die Methoden close handleFault und getHeaders werden von uns in aller Regel gar nicht weiter beachtet. Uns interessiert tatsächlich nur die Methode handleMessage. In dieser Methode setzen wir zunächst die Rückgabe auf true um zu zeigen, dass eine wie auch immer geartete Verarbeitung erfolgreich war. Nun werden wir die eigentliche SOAP-Message, die vom Client zum Server geschickt wird, referenzieren. Das geschieht mit Hilfe der übergebenen SOAPMessageContext-Instanz und deren Methode getMessage. Wir referenzieren nun das SOAPEnvelope-Element. Das holen wir uns aus der Message über die Methode getSOAPPart und dann die untergeordnete Methode getEnvelope. Hierbei kann es zu einer Exception kommen. Die werden wir behandeln. Die weitere Verarbeitung findet nun im generierten Triblock statt. Jetzt referenzieren wir das SOAPHeader-Element. Dafür verwenden wir ... die Methode getHeader der Envelope-Instanz. Es muss nicht zwingend so sein, dass ein Header gesetzt ist. Deswegen prüfen wir hier erstmal, ob er tatsächlich existiert. Wenn er nicht existiert, legen wir ihn neu an, und zwar über die Methode addHeader der soapEnvelope-Instanz. Nachdem wir so sichergestellt haben, dass es wenigstens einen Header gibt, können wir nun unser zusätzliches Element erzeugen. Das Ganze wird repräsentiert über ein QName-Element. Dies erlaubt es uns, einen eigenen Namensraum für unser zusätzliches Header-Element zu definieren, damit wir später in der Lage sind, das eindeutig zu identifizieren. Der Name unseres Header-Elements wird AUTH heißen. Der Namensraum ist frei wählbar. Wir nennen ihn mal urn:de.video2brain.services. Diesen Namen müssen wir uns merken, wir benötigen ihn später erneut. Nun können wir ein sogenanntes soapHeaderElement erzeugen. Das erzeugen wir über die Methode addHeaderElement der soapHeader-Klasse. Dabei übergeben wir den eben erzeugten QName. Auf Ebene dieses soapHeader-Elements geben wir nun über die Methode setActor an, wie weiter verfahren werden soll. Wir geben hier mehr oder weniger eine Konstante hinein. SOAPConstants.URI_SOAP_ACTOR_NEXT Das bedeutet nichts anderes, als dass der nächste Actor in der Verarbeitungskette im Zweifelsfall dieses Element behandeln soll. Für uns viel relevanter ist allerdings die Auskunft, dass dieses soapHeaderElement einen textuellen Content beinhalten soll. Das machen wir über addTextNode und hier geben wir jetzt den eigentlichen Wert dieses Elementes aus. Jetzt haben wir die Message, die wir möchten, bereits fertig manipuliert. Wir werden jetzt noch die Änderungen speichern und einmal die Nachricht als solches einmal nach system auth ausgeben, damit wir sie in der Konsole auch verfolgen können. Hierbei kann es ebenfalls noch zu einer Exception kommen. die wir dann einfach dem umgebenden Triblock mit hinzufügen können. Damit ist die Verarbeitung auf der Client-Seite soweit abgeschlossen. Wir müssen nur noch den Handler mit dem Client als solches registrieren. Die Registrierung ... (tippt) ... geschieht, nachdem wir den Web-Service-Client als solches erzeugt haben. Wir machen das gleich mit Hilfe einer HandlerResolver-Instanz. Das ist eigentlich eine Klasse. Weil da sehr wenig Code drinsteht, implementieren wir sie in-line. Wir fügen über die Methode setHandlerResolver eine neue HandlerResolver-Instanz hinzu und die verfügt letztlich nur über eine einzige Methode, nämlich getHandlerChain. Es können mehrere Handler definiert sein. Wir definieren, dass es tatsächlich nur einen einzigen Handler gibt. Und zwar in Form einer java.util-List vom Typ Handler, implementiert als ArrayList vom Typ Handler und fügen dann dieser Liste unseren gerade eben definierten AuthenticationClientHandler hinzu. Und wir geben sie zurück. Damit ist dieser ClientHandler fertig implementiert und in den Web-Service-Client auch eingefügt worden. Nun können wir einmal den Web Service als solches aufrufen. Wir sollten dann auf der Konsole sehen, dass die Nachricht manipuliert worden ist. Hier sehen wir die eigentliche Nachricht, die generiert worden ist. Wir bekommen sie zweimal, weil wir zwei Aufrufe auf den Web-Server haben. Im Envelope-Element befindet sich nun ein Header-Element. Dieses Header-Element beinhaltet das von uns gerade definierte Auth-Element mit dem entsprechend hinterlegten Wert, der dann an den Server übergeben wird. Auf Serverseite passiert jetzt noch nichts. Dort ist im Grunde dieselbe Tätigkeit noch einmal zu erledigen, nämlich einen entsprechenden SOAPHandler zu implementieren der dann eine Verarbeitung dieses Headers vornimmt. In diesem Video haben wir uns damit auseinandergesetzt, wie wir SOAPHandler auf Client-Seite implementieren können und wie wir sie an den eigentlichen Web-Service-Client binden können. Wir haben uns auch etwas über die Hintergründe hinter SOAPHandlern und deren Einsatzspektren unterhalten.

Java EE 7: Web Services

Steigen Sie ein in die Java-Enterprise-Welt und lernen Sie, wie Nachrichten ausgetauscht und Dienste definiert werden.

5 Std. 13 min (30 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!