Java EE 7: Web Services

Absichern eines Web Services

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Um Web Services abzusichern, gibt es verschiedene Ansätze - der Server selbst übernimmt die Sicherung, der Service kümmert sich darum oder man setzt zusätzliche Frameworks wie etwa WS-Security ein.

Transkript

Nicht immer sollen Web Services frei im Netz verfügbar sein. Sie werden dann zwar auf einer Webseite bereitgestellt, allerdings soll der Zugriff nur für bestimmte Benutzer, Benutzergruppen oder Applikationen gewährleistet sein. Wie wir dies umsetzen können, besprechen wir in diesem Video. Wenn wir über die Sicherheit oder das Absichern von Web Services reden, unterscheiden wir grundsätzlich drei mögliche Ansätze. Zum einen die sogenannte containerbasierte Sicherheit. Hier wird es dem Web-Server selbst überlassen, dafür zu sorgen, dass nur berechtigte Personen oder Applikationen auf unseren Web Service zugreifen dürfen. Dabei verwenden wir Mechanismen wie Basic Authentication, oder die Windows-Authentifizierung. Ein anderer Ansatz ist die sogenannte applikationsbasierte Sicherheit. Hier ist der Web-Server als solches außen vor. Der Zugriff als solches wird also nicht weiter überprüft. In jedem Fall wird aber auf Ebene der Applikation bei jedem Zugriff auf eine der Funktionalitäten sichergestellt, dass zum Beispiel bestimmte Header-Werte gesetzt sind. Sind diese nicht gesetzt, wird die Operation nicht ausgeführt. So kann die Applikation selbst fein granular steuern, wer oder was bestimmte Funktionalitäten nutzen darf. Die dritte Möglichkeit stellt die Verwendung übergreifender Standards, beispielsweise WS-Security oder WS-Encryption dar. Dabei werden die Nachrichten, die zwischen Client und Server ausgetauscht werden, also die SOAP-Nachrichten, um entsprechend zusätzliche Informationen angereichert beziehungsweise verschlüsselt Da WS-Security und WS-Encryption relativ aufwendig zu implementieren sind und vor allem sehr, sehr viel Konfigurationsaufwand erfordern, werden wir uns an dieser Stelle nicht weiter um diese beiden Ansätze kümmern. Wir setzen uns im folgenden mit dem containerbasierten Ansatz auseinander. Dieser Ansatz besagt, dass die Sicherheit bereits auf Ebene der Applikationen gewährleistet wird. Oder anders ausgedrückt: Keine einzige Funktionalität eines Web Services lässt sich aufrufen, wenn der Benutzer nicht über die entsprechenden Zugriffsrechte verfügt. Dies wird vom Application Server beziehungsweise vom Web-Server bereits abgeklärt, indem mit Hilfe von Standardmechanismen der Zugriff gesichert wird. Das sind zum Beispiel Mechanismen wie Basic-Authentifizierung oder die Guest-Authentifizierung. Grundsätzlich gilt: Ist der Benutzer nicht authentifiziert, muss er sich authentifizieren. Ist er authentifiziert, wird die Ressource nur aufgerufen, wenn der Zugriff tatsächlich gewährleistet ist. Welche Benutzer beziehungsweise welche Benutzergruppen auf eine Ressource zugreifen dürfen, wird in der Konfigurationsdatei web.xml konfiguriert. Damit man das ganze dann entsprechend umsetzen kann, muss man zunächst mindestens einen Applikationsbenutzer anlegen. Dies werden wir im folgenden tun und im WildFly-Server einen neuen Benutzer anlegen. Im Bin-Verzeichnis des WildFly-Servers befindet sich das Script add-user. Dieses Script erlaubt es uns, entweder einen Management- oder einen Applikations-Benutzer anzulegen. Wir wollen in diesem Fall einen Management-Benutzer anlegen. Wir geben den Buchstaben b ein und drücken auf Enter. Jetzt können wir einen frei wählbaren Benutzernamen vergeben. Ich entscheide mich hier für den Benutzernamen test. und vergebe ein sicheres Kennwort. Das Kennwort ist nicht ganz so sicher, deswegen muss ich diese Frage nochmal beantworten. Nachdem ich das Kennwort ein zweites Mal eingegeben habe, kann ich nun die Gruppen angeben, die diesem Benutzer zugeordnet werden sollen. Das sind frei wählbare Zeichenketten; ich kann mehrere durch Kommata voneinander trennen. Es gibt hier genau eine Gruppe, nämlich WebServices. Jetzt werde ich noch einmal gefragt, ob alles OK ist. Jawohl, das ist es. Der Benutzer soll angelegt werden und nein, dieser Benutzer wird nicht benutzt, um zu einem Application Server- Prozess zu verbinden. Damit ist das Anlegen des Benutzers abgeschlossen und ich kann mich um die Konfiguration meiner Web-Applikation kümmern. Nun kann ich die Web-Applikation konfigurieren. Zu diesem Zweck werde ich die Datei web.xml, die sich innerhalb des WEB-INF-Verzeichnis der Web-Applikation befindet, entsprechend anpassen. Sollte diese wie in meinem Fall noch nicht existieren, können Sie sie einfach hinzufügen, indem Sie einen Rechtsklick auf WEB-INF machen und dann New Other, und XML File auswählen. Benennen Sie diese Datei in web.xml um. Die so angelegte Datei verfügt noch über keinerlei Inhalt und muss jetzt mit dem Format des Standard-Deployment-Descriptors für eine Java-EE7-Webapplikation befüllt werden. Ich habe zu diesem Zweck auf meinem Blog einen Link zu einer Webseite bereitgestellt, die uns genau diese Informationen liefert. Sie finden das unter www.samaschke.de/blog entsprechend aufbereitet. Nachdem wir nun den Standard- Deployment-Descriptor erstellt haben, müssen wir diesen noch an unsere Bedürfnisse anpassen. Das heißt, wir müssen die Sicherheit konfigurieren. Zu diesem Zweck werden wir im ersten Schritt einmal sagen, welche Art von Authentifizierung stattfinden soll. Das machen wir über ein Login-Config-Element. Dieses Login-Config-Element verfügt über ein untergeordnetes Auth-Method-Element. Hier geben wir den Wert BASIC an, um Basic Authentication zu benutzen. Das ist streng genommen eine der unsichersten Varianten, weil Benutzername und Kennwort nur base-64-kodiert übertragen werden. Für ein echtes Projekt würde ich zumindest noch die SSL-Verschlüsselung einsetzen, ansonsten zum Beispiel auf die Guest-Authentifizierung setzen. Aber für unsere Zwecke sollte das ausreichend sein. Dann geben wir an, welche Rollen wir tatsächlich in dieser Applikation verwenden wollen. Die Rollen ergeben sich aus dem, was wir beim Anlegen des Benutzers gesagt haben. Ich kann beim Anlegen eines jeden Benutzers beliebige Rollen, durch Kommata getrennt, definieren. Und hier referenziere ich die entsprechenden Rollennamen. Das mache ich, indem ich ein Security-Role-Element hinzufüge samt untergeordnetem Role-Name-Element. Der Rollenname lautet WebServices. Nun muss ich die eigentliche Sicherheitseinstellung vornehmen. Das mache ich über ein Security-Constraint-Element. Dieses Element verfügt über eine Web Resource Collection. Das sind letztlich alle zu schützenden untergeordneten Ressourcen in der Webapplikation. Es kann von diesen Security Constraints mehrere geben. Uns reicht natürlich einer aus. Wir wollen ja auch nur eine Ressource schützen. So einer Web Resource Collection können wir einen schönen sprechenden Namen geben. Das machen wir dann über Web Resource Name. Und wir geben über das sogenannte URL Pattern an, welche Adresse tatsächlich zu schützen ist. In unserem Fall die Adresse unseres TestWebService. Nun geben wir zuletzt mit Hilfe von Auth Constraint an, welche der weiter unten definierten Rollen – wir haben nur eine Rolle, aber es könnten ja mehrere sein – Zugriff erhalten, nämlich die Web Services-Rollen. Damit haben wir unsere Webapplikation soweit abgesichert. Wir werden sie nun einmal starten und dann versuchen, über den Browser auf diese Webapplikation zuzugreifen. Zu diesem Zweck mache ich einen Rechtsklick auf die Java-EE-Applikation und wähle Run as Run on Server aus. Ich lasse das dann auf dem WildFly-Server laufen. Ich werde den Server sicherheitshalber noch einmal synchronisieren. Wenn ich nun versuche, auf meinen Web Service zuzugreifen, muss ich mich anmelden. Wenn ich hier die korrekte Kombination aus Benutzername und Passwort angebe, kann ich auf das WSDL zugreifen. Ansonsten ist dies nicht möglich. Ich werde nun dieses WSDL speichern. Zu diesem Zweck öffne ich die Seite direkt im Internet Explorer. Jetzt kann ich über die Seite entsprechend speichern. TestWebService.wsdl ist ein sehr guter Name. Nun öffne ich den Windows Explorer und ziehe das so gespeicherte WSDL-File auf mein Client-Projekt. Ich kopiere es hinein und benenne die Datei noch korrekt um. Das ist nicht unbedingt nötig, sollte man allerdings machen, damit man einfach einen schöneren Namen dort hat. Die Dateiendung .xml, die vom Internet Explorer hinzugefügt worden ist, ist nicht wirklich hilfreich. Jetzt kann ich auch einen Doppelklick drauf machen und sehe auch direkt in der WSDL-Ansicht oder in einem speziellen Designer, welche Funktionalitäten uns zur Verfügung stehen. Damit sind wir auch schon beim Client. Den Web Service-Client muss ich nun noch so konfigurieren, dass er ebenfalls mit unserer neuen abgesicherten Variante des Web Service arbeiten kann. Wir schauen erstmal, ob er überhaupt funktioniert. Nein, es gibt einen Fehler. Dieser Fehler wirkt sich auf zwei Ebenen aus, nämlich einerseits beim Zugriff auf die Methoden und andererseits schon beim Erstellen des Services. Widmen wir uns zunächst dem Zugriff auf die Methoden. Um hier zu verhindern, dass es eine Exception beim Zugriff gibt, werde ich einen BindingProvider verwenden und konfigurieren. Dieser BindingProvider erlaubt es uns, per Anfrage zusätzliche Informationen hinzuzufügen. Wir fügen zu diesem Zweck eine BindingProvider-Instanz ein. An diese Instanz kommen wir über die bereits referenzierte Port-Instanz heran, indem wir sie einfach in BindingProvider konvertieren. Nun kann ich dem Provider über dessen Request Context zusätzliche Informationen hinzufügen. Einerseits den Benutzernamen. Das mache ich über BindingProvider.USERNAME. ... und ... ... das Kennwort. Damit ist allerdings der Web Service als solches immer noch nicht benutzbar. Kurz noch einmal nachgeschaut. Wir sehen weiterhin dieselbe Fehlermeldung. Wenn wir sie uns genauer anschauen, sehen wir, dass auf den Web Service unter Angabe des Parameters WSDL zugegriffen wird. Das Ganze geschieht beim Erzeugen der Instanz des Web Services. Da müssen wir ebenfalls Änderungen vornehmen. Zu diesem Zweck haben wir vorhin das WSDL-File gespeichert und unserer Applikation hinzugefügt. Wir werden es nun hier einbinden. Nun werden wir eine Überladung des Konstruktors der TestWebService-Serviceklasse nutzen. Und zwar die Variante, die eine URL-Instanz entgegennimmt. Diese URL-Instanz verweist auf die von uns heruntergeladene Datei und ich verwende eine File-Instanz, um das Ganze zu referenzieren. (tippt) Wir benötigen den kompletten Pfad. Den holen wir uns über diese File-Instanz. Wir können nun eine neue URL-Instanz erzeugen. Wichtig ist hier die Angabe des Protokolls file. Dann kommt der eigentliche Pfad. Es kann an dieser Stelle zu einer Exception kommen, falls die URL im Sinne einer URL ungültig ist. Vielleicht fehlt die Pfadangabe. Wir können diese per Tricatch behandeln. Oder wir fügen der Methodensignatur eine throws declaration hinzu. Wir haben uns für letzteren Fall entschieden und können nun schnell weiterarbeiten. Jetzt können wir die eigentliche Service-Instanz erzeugen. Hier verwenden wir diesmal den Konstruktor Unterangabe der eben erzeugten URL-Instanz. Damit ist unser Web Service fertig konfiguriert und unser Client ist ebenfalls fertig konfiguriert und kann mit diesem Web Service arbeiten. Wir schauen es uns einmal an, indem wir den Client laufen lassen. Wir werden feststellen, es gibt keine Fehler mehr. Das heißt, Client und Service können miteinander kommunizieren. Wir haben in diesem Video besprochen, welche Formen der Absicherung von Applikationen es gibt. Wir können sowohl die containerbasierte Applikationsabsicherung nutzen oder verwenden die applikationsbasierte Absicherung von Web Services oder wir greifen auf Standards zurück. Letztere sind besonders schwierig zu implementieren. Wir haben uns hier etwas intensiver mit der Absicherung eines XML Web Services per Basic Authentication auseinandergesetzt. Wir haben sowohl den Service konfiguriert als auch den Web Service-Client und sie miteinander so zum Arbeiten bekommen, dass sie zwar interagieren können, aber ein unberechtigter Benutzer den Web Service nicht mehr aufrufen kann.

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!