Darstellung von Absicherungsmöglichkeiten für den Datenaustausch mithilfe von SOAP

Sicherheit für SOAP mit Tomcat und Axis

Dr. Arndt Schönberg

Zur Kommunikation zwischen Anwendungen (z.B. einem Point of Sale und einem Back-Office-System) oder bei der Erstellung von SOA sind klare und sichere Schnittstellen zwischen den unterschiedlichen Anwendungen notwendig. Eine flexible Art, solche Schnittstellen zu realisieren, ist die Verwendung des SOAP-Protokolls. Eine der verbreitetsten SOAP-Implementierungen ist natürlich Apache Axis. Axis wird häufig in dem Servlet-Container Apache Tomcat betrieben. Wird eine solche Architektur angestrebt, gibt es verschiedene Ansatzpunkte zur Realisierung einer abgesicherten Kommunikation.

Mit den folgenden Ausführungen wird ein Überblick über die Absicherungsmöglichkeiten eines häufig vorkommenden Szenarios bei der Anbindung von Diensten in eine Gesamtarchitektur vorgestellt. Eine Anwendung A möchte über ein (unsicheres) Netzwerk Daten mit einer Anwendung B austauschen. Zur Realisierung einer Schnittstelle, die von unterschiedlichsten Plattformen bedient werden kann, wurde SOAP als Technologie gewählt. Es ergibt sich der Aufbau in Abbildung 1.

Abb. 1: SOAP-Kommunikation zwischen Client und Backend

Die eigentliche SOAP-Schnittstelle gliedert sich in den SOAP-Client, der mit der Anwendung A verbunden ist und die zu versendenden Daten in eine SOAP-Nachricht verpackt. Auf der anderen Seite befindet sich der SOAP-Server, der die SOAP-Nachricht entgegennimmt und den Nachrichtenanteil an Anwendung B weitergibt. Bei einer synchronen Kommunikation erstellt Anwendung B die Antwortdaten und gibt diese über den SOAP-Server in einer SOAP-Antwort an den SOAP Client zurück.

In dem im Weiteren betrachteten Szenario wird der SOAP-Server als Dienst in Axis 2 betrieben. Axis 2 wiederum ist als Servlet in Tomcat 5.5.x installiert. Wie sich im Folgenden zeigen wird, sind einige Funktionen von Axis 2 in der Version 1 noch nicht vollständig vorhanden. Axis 2 wurde dennoch gewählt, da u.a. wegen des sehr performanten XML-Objektmodells AXIOM und den integrierten WS-Security-Funktionen Axis 2 gute Aussichten hat, an den Erfolg von Axis 1.x [1] anzuschließen und diese Implementierung auf Dauer abzulösen.

Gefahren auf der Reise

Um eine sichere Kommunikation zu ermöglichen, muss sichergestellt werden, dass beide Kommunikationspartner wissen, mit wem sie reden und dass die übermittelten Anfragen und Antworten nicht von einer dritten Partei abgehört werden können. (Wer möchte schon, dass die letzten Verkaufsdaten der Niederlassung in China von jedem eingesehen werden können.) Es ist also zu klären, wie sich die Gesprächspartner authentifizieren und wie die Daten sicher übertragen werden können. Nicht eingegangen wird auf die Absicherung gegen Hacker – also auf die Absicherung der Installation von Tomcat und Axis durch beispielsweise das Einspielen von Patches, Aktualisierung des Betriebssystems und Zugangskontrollen. Für den Betrieb von Tomcat bietet z.B. Lajos Moczar: Tomcat 5 – Einsatz in Unternehmensanwendungen mit JSP und Servlets (Addison-Wesley, 2004) einen guten Überblick.

Transportschutz

Um die übertragenen Daten zu schützen, hat sich bei vielen Anwendungen (z.B. Online-Shops, Banking) der Einsatz von TLS (Transport Layer Security) bzw. SSL (Secure Sockets Layer) durchgesetzt. Bei TLS handelt es sich um eine Weiterentwicklung des Verschlüsselungsprotokolls SSL. Im allgemeinen Sprachgebrauch und in diesem Artikel wird für beide Varianten SSL als Bezeichnung verwendet.

SSL arbeitet oberhalb der Transportschicht (nach OSI-Modell) und unterhalb der Anwendungsschicht für die Anwendungen transparent. Durch die Verwendung von SSL tauschen die Gesprächspartner Schlüssel aus, mit deren Hilfe die verschickten Nachrichten verschlüsselt werden. Damit eine verschlüsselte Verbindung zu einem Server aufgebaut werden kann, muss dieser ein Zertifikat bereitstellen, das vom Client akzeptiert werden muss. Überprüft der Client die Echtheit (z.B. durch Vergleich des Fingerprints), kann er nicht nur davon ausgehen, dass die Kommunikation nicht abgehört werden kann, sondern auch, dass der Gesprächspartner (Server) der ist, für den er sich ausgibt.

Eine einfache Möglichkeit, die Clients einzuschränken, die mit dem Server kommunizieren dürfen, besteht darin, die IP-Adressen einzuschränken, von denen Tomcat eine Verbindung annimmt. Hierfür kann die Konfigurationsdatei server.xml um das Attribut RemoteAddrValve erweitert werden. Beispielsweise werden durch die Zeile

localhost und der Adressenbereich 1.10.*.* für eine Kommunikation zugelassen. Alle Anfragen von anderen Adressen werden abgelehnt. Da dieses Verfahren keine Authentifizierung im eigentlichen Sinne enthält und nur funktioniert, wenn alle Clients feste IP-Adressen besitzen, wird im Folgenden auf andere Möglichkeiten der Authentifizierung eingegangen.

Wer bist du?

Die möglichen Authentifizierungsmethoden für eine SOAP-Schnittstelle können danach unterschieden werden, an welchem Punkt der Verbindung die Auswertung der Anmeldeinformationen stattfindet. Ohne Anspruch auf Vollständigkeit kann z.B. bei dem Aufbau der Verbindung mithilfe von Zertifikaten nicht nur die Identität des Servers, sondern auch die der Clients geprüft werden. Auf Ebene der Servlets – Axis 2 läuft als Servlet im Tomcat – kann Tomcat Berechtigungen prüfen. Innerhalb von Axis 2 kann das Modul RAMPart eingesetzt werden, dass eine Implementierung der OASIS Web Services Security [2] [3] ist. Weiterhin kann die Authentifizierung auch in die nachgelagerten Anwendungen verschoben werden, indem man die Anmeldeinformationen in diesen Anwendungen ausliest (z.B. Übertragung in den Nutzdaten) und auswertet.

Abb. 2: Alternativen der Nutzer-Authentifizierung

Die Verwendung von SSL-Client-Zertifikaten für eine beidseitige Authentifizierung wird für die Absicherung des betrachteten Szenarios selten verwendet. Dies mag daran liegen, dass die in den Schlüsselspeichern der Anwendungen erwarteten Zertifikate schwieriger zu verwalten sind und sich für die Authentifizierung von Nutzern klassische Login-Passwort-Kombinationen eher eignen. Aus diesem Grund werden Client-Zertifikate hier nicht weiter behandelt. Eine der wenigen (älteren) Dokumentationen zu dem notwendigen Vorgehen findet sich in [4].

Container-Based/HTTP Basic-Authentifizierung

Tomcat stellt verschiedene Authentifizierungsmechanismen, so genannte Realms, zur Verfügung, die eine Authentifizierung realisieren. Bei diesen Mechanismen können verschiedene Datenspeicher (Datei, Datenbank, LDAP Server …) zur Verwaltung der Anmeldeinformationen verwendet werden. Zu einem Nutzer werden in diesen Datenspeichern Login, Passwort und Gruppenzugehörigkeiten verwaltet. Auf Basis dieser Informationen wird in den Konfigurationsdateien von Tomcat festgelegt, welche Nutzer auf die einzelnen Servlets Zugriff haben. Da Axis 2 als Router-Servlet in Tomcat betrieben wird, können über diesen Mechanismus die Zugriffe auf Axis 2 beschränkt werden. Diese Beschränkung gilt dann für alle SOAP-Dienste, die in dem Router-Servlet laufen. Sollen SOAP-Dienste mit unterschiedlichen Rechten definiert werden, muss das Router-Servlet mehrmals installiert werden. Wenn die Authentifizierung von Tomcat durchgeführt wurde, kann das Servlet ebenfalls auf die Anmeldeinformationen zugreifen und so eine weitere Prüfung durch die Anwendung durchführen.

Die Konfiguration von Tomcat in der und von Axis in der Datei web.xml ist u.a. in [1] und [4] beschrieben.

Um diese Authentifizierung zu verwenden, muss in dem SOAP-Client Basic-Authentifizierung realisiert werden. Dies geschieht im Allgemeinen durch Erfassen der notwendigen Informationen im HTTP Header. Hier zeigt die Version 1.0 Version von Axis 2 eine gravierende Schwäche. In der derzeit zum Download stehenden Version ist das Setzen der Informationen für die Basic-Authentifizierung nicht (mehr) möglich, da die entsprechende Klasse fehlt. In dem aktuellen Snapshot ist diese Funktionalität aber wieder zu finden, sodass in dem kommenden Release Basic-Authentifizierung wieder verwendet werden kann.

Wenn die entsprechende Klasse

org.apache.axis2.transport.http.HttpTransportProperties.BasicAuthentication 

zur Verfügung steht, können die Authentifizierungsinformationen an Instanzen der Klassen ServiceClient oder OperationClient gebunden werden. Dies geschieht in den jeweiligen Optionen.

HttpTransportProperties.BasicAuthentication basicAuthentication =
             new HttpTransportProperties().new BasicAuthentication();

basicAuthentication.setUsername("Username");
basicAuthentication.setPassword("myPass");

OperationClient operationClient = new OperationClient();
operationClient.getOptions().setProperty(
org.apache.axis2.transport.http.HTTPConstants.BASIC_AUTHENTICATION,
                    basicAuthentication);

Zu beachten ist bei dieser Art der Authentifizierung, dass sie auf HTTP basiert. Da SOAP auch mit anderen Transportprotokollen funktioniert, ist dies eine Einschränkung.

WS-Security

Speziell zur Absicherung von Web Services ist WS-Security entwickelt worden [5]. Für Java ist WS-Security in dem Apache-Projekt WSS4J realisiert. Die wichtigsten Funktionen sind Authentifizierung, Signierung und Verschlüsselung. In Bezug auf die bisherigen Ausführungen ist bei diesem integrierten Ansatz der unterschiedlichen Sicherheitsmechanismen insbesondere der letzte Punkt interessant. Durch die Verschlüsselung der Nachrichten ist die Verschlüsselung des Transportwegs mit SSL nicht mehr zwingend erforderlich – wenn auch nicht schädlich.

Im Allgemeinen werden die Funktionen von WSS4J nicht direkt in den Sourcecode eingebunden, sondern die verwenden Sicherheitsfunktionen in Konfigurationsdateien beschrieben. Für Axis 2 gibt es zur Realisierung von WS-Security das Modul Rampart. Dieses wird in Axis 2 eingebunden und für Server und Client in service.xml und axis2.xml entsprechende Parameter gesetzt. Eine Beschreibung über den Einsatz findet sich unter [6]. Weitere Informationen zur Anwendung von Rampart finden sich unter [7] und [8].

Anwendungsspezifischer Code (Custom Security)

Bei Verfahren, die die Custom Security realisieren, wird die Authentifizierung durch die Anwendungen hinter der SOAP-Schnittstelle – und nicht durch vorgelagerte Software wie Tomcat oder das Axis-Servlet – durchgeführt. Hierfür werden die Anmeldeinformationen in den Nutzdaten der SOAP-Nachricht verpackt und durch den Server an die Anwendung weitergereicht (auch die Auswertung von HTTP-Header-Informationen ist in Anwendungen möglich). Der große Nachteil der Custom Security liegt darin, dass „das Rad neu erfunden wird“ und somit ein hoher Aufwand und eine höhere Fehlerwahrscheinlichkeit als bei den etablierten und vielfach getesteten Verfahren besteht. Als zusätzlicher, verfeinerter Autorisierungsschritt, der auf vorgelagerte Informationen zugreift, kann Custom Security jedoch sinnvoll sein.

Zusammenfassung

Es gibt verschiedene Möglichkeiten, SOAP-Dienste abzusichern. Die Verwendung von SSL als Sicherung der Verbindung und der Echtheit des Servers ist, wenn keine WS-Security eingesetzt wird, unverzichtbar. Für die Verwendung von HTTP-Authentifizierung spricht, dass es eine bekannte Technologie ist, die insbesondere die Einstiegshürden reduziert. Leider ist die derzeitige Implementierung von Axis 2 an dieser Stelle noch nicht vollständig. Wenn HTTP-Authentifizierung kurzfristig verwendet werden soll, muss also auf Axis 1.x zurückgegriffen werden. In naher Zukunft wird dieses Manko in Axis 2 jedoch behoben sein. Die Verwendung von SSL-Client-Zertifikaten wird sicherlich nur in Sonderfällen verwendet werden, da der Einsatz komplizierter und die Sicherheit nicht höher sind als bei HTTP-Authentifizierung über SSL.

Zukünftig wird die Absicherung von SOAP-Diensten mithilfe von WS-Security deutlich an Bedeutung gewinnen. Insbesondere dadurch, dass die Sicherheitsfunktionen Verschlüsselung und Authentifizierung integriert zur Verfügung stehen, ist eine einfachere Konfiguration und Anwendungsentwicklung möglich, als bei der SSL-/HTTP-Authentifizierung. Zusätzliche Funktionen wie die Signierung werden an Bedeutung gewinnen und stehen in diesem Ansatz ebenfalls integriert zur Verfügung.

Die Custom Security sollte nur für nachgelagerte Auswertungen der Sicherheitsmerkmale verwendet werden. Die Basisauthentifizierung sollte durch die zuvor beschriebenen Standardmechanismen erfolgen.

Wie die Ausführungen gezeigt haben, stehen der sicheren Anwendung von SOAP-Diensten über unsichere Netze heutzutage nur noch kleinere Unwegbarkeiten im Wege. Somit sollte die vielfach praktizierte Sicherung der Dienste durch Geheimhaltung der Adresse (security by obscurity) bald der Vergangenheit angehören.

Tomcat auf SSL vorbereiten

Um durch SSL gesicherte Verbindungen aufbauen zu können, muss der Server ein entsprechendes Zertifikat bereitstellen. Es ist möglich selbst signierte Zertifikate oder Zertifikate, die durch öffentliche Stellen vergeben und beglaubigt wurden, zu verwenden. Im Folgenden werden selbst signierte Zertifikate, die mithilfe eines privaten Schlüssels signiert wurden, betrachtet. Ein so beglaubigtes Zertifikat wird Tomcat in einem vertrauenswürdigen Schlüsselspeicher zur Verfügung gestellt.

Die folgenden Ausführungen beziehen sich auf eine Windows-XP-Installation. Die notwendigen Schritte unter Linux-Distributionen sind analog zu diesen. Alternativ zu dem verwendeten Java-Tool können Zertifikate auch mit OpenSSL erstellt werden.

Erzeugen eines Schlüssels und Zertifikats

Um einen Schlüssel zu erzeugen, mit dessen Hilfe Zertifikate beglaubigt werden können, wird das mit dem JDK installierte Tool keytool verwendet. Führen Sie in einer MS-Dos-Box folgenden Befehl aus, der einen RSA-Schlüssel „tomcat“ der Länge 1024 mit dem namen „SOAP-SERVER“ in einem Basisschlüsselspeicher (keystore) in dem conf-Verzeichnis von Tomcat ablegt. Mit dem Wert, der hinter „CN=“ angegeben wird, wird der Common Name angegeben, der den Eigentümer des Zertifikats bezeichnet. und sind durch die Passwörter für den Schlüssel und den Schlüsselspeicher zu ersetzen.

%JAVA_HOME%jrebinkeytool -genkey -alias tomcat -keyalg RSA -keysize 1024 -dname „CN=SOAP_SERVER“ -keypass -storepass -keystore %CATALINA_HOME%confkeystore

Im nächsten Schritt wird ein Zertifikat mit der Bezeichnung tomcat-server.crt erzeugt und mit dem erstellten Schlüssel signiert. Dieses Zertifikat wird ebenfalls in den Schlüsselspeicher abgelegt. Nach Eingabe des Befehls

%JAVA_HOME%jrebinkeytool -export -alias tomcat -file %CATALINA_HOME%conftomcat-server.crt -keystore %CATALINA_HOME%conf.keystore

wird das Schlüsselspeicher-Passwort erfragt und das Zertifikat abgelegt. Um das Zertifikat verwenden zu können, muss dieses Tomcat in einem Schlüsselspeicher zur Verfügung gestellt werden. Mit dem folgenden Befehl wird das Zertifikat in den Schlüsselspeicher cacerts übernommen (und dieser ggf. angelegt).

%JAVA_HOME%jrebinkeytool -import -file tomcat-server.crt -keystore %CATALINA_HOME%CONFcacerts

Da hier auf den Basisschlüsselspeicher zugegriffen wird, muss das Passwort eingegeben und das Vertrauen bestätigt werden.

Tomcat konfigurieren

Um das Zertifikat zu verwenden, muss die Konfiguration von Tomcat angepasst werden. Hierfür muss die Datei %CATALINA_HOME%confServer.xml um die Zeilen in dem folgenden Listing nach der Connector-Definition für Port 8080 in der Standardkonfiguration eingefügt werden.

Es wird ein Connector für Port 8443 erzeugt, der keine Client-Authentifizierung benötigt, und als Protokoll TLS verwendet. In den letzten Parametern werden der Basis-Schlüsselspeicher und das zugehörige Passwort und der Schlüsselspeicher der vertrauenswürdigen Zertifikate angegeben.

Ab diesem Zeitpunkt wird alle Kommunikation über Port 8443 verschlüsselt. Beim ersten Aufruf eines Servlets über diesen Port (nicht vergessen https statt http zu verwenden) muss der Client dem erstellen Zertifikat vertrauen.

TLS / SSL connector
-----------------------------------------------

Dr. Arndt Schönberg studierte Informatik und promovierte zum Ingenieur. Er ist als IT-Berater mit den Schwerpunkten neue Technologien und OO/Enterprise-Jaav für seine Firma schönberg-solutions) tätig.
Geschrieben von
Dr. Arndt Schönberg
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.