Gegenseitige SSL-Authentifizierung mit Websphere Application Server und CXF

Überblick In meinem aktuellen Projekt laufen einige der Webservices, zu denen wir eine Verbindung herstellen müssen, in einer nicht-firewalled Umgebung. Um zu verhindern, dass unbefugte Clients eine Verbindung zu diesen Diensten herstellen, haben die Administratoren beschlossen, dass es ein guter Plan ist, eine gegenseitige Authentifizierung mit SSL zu verwenden. Da alle diese Verbindungen innerhalb der Intranet-Umgebung meines Kunden laufen, werden die Zertifikate nicht von einer weltweit vertrauenswürdigen Zertifizierungsstelle (wie VeriSign) signiert, sondern von einer internen Zertifizierungsstelle, die standardmäßig nicht vertrauenswürdig ist. Global gesehen sieht das Bild so aus: [WAS]--https->[[IHS]--http->[WAS]] WAS = Websphere Application Server IHS = IBM HTTP Sever (Apache mit Extras) Wir haben Webservice-Clients, die in WAS laufen und Apache CXF, ein Open Source Services Framework, zur Kommunikation mit Webservice-Anbietern verwenden. Diese Anbieter werden auf einer anderen WAS-Instanz ausgeführt. Die HTTPS-Verbindung endet am IHS, der auf demselben Rechner läuft wie die WAS-Instanz, mit der die Verbindung hergestellt werden soll. Die WAS-Instanz ist dann so konfiguriert, dass sie nur Verbindungen von localhost zulässt.

Umfang dieses Beitrags Damit das funktioniert, mussten wir alles Mögliche tun:

• Generieren Sie Zertifizierungsanfragen für alle Zertifikate
• Abrufen der von der internen Behörde signierten Zertifikate
• Konfigurieren Sie diese signierten Zertifikate korrekt in WAS und IHS (Client und Server)
• Bringen Sie sowohl den Server als auch den Client dazu, diesen intern signierten Zertifikaten zu vertrauen

In diesem Beitrag geht es darum, wie Sie die Client-Authentifizierung in einer Webanwendung, die Webdienste aufruft, zum Laufen bringen. Allgemeine Dinge wie das Signieren von Zertifikaten und dergleichen sind im Internet gut dokumentiert, so dass ich darauf nicht näher eingehen werde. Der Rest dieses Beitrags geht also davon aus, dass Sie über gültige, signierte Zertifikate verfügen. Client-seitige Konfiguration Unsere Client-Anwendungen müssen die HTTPS-Verbindung zu den Servern einrichten und die gesamte Konfiguration dafür musste im WAS liegen (eine Wartungsanforderung). Die CXF-Clients, die wir haben, sollten also nicht konfiguriert werden müssen, um zu wissen, wo die Schlüsselspeicher sind, wie die Passwörter lauten und so weiter. Sie sollten "einfach funktionieren".Sie können dies in WAS wahrscheinlich auf eine Million Arten konfigurieren, aber wir haben es so gemacht, dass wir eine so genannte"Dynamische ausgehende SSL-Konfiguration" erstellt haben. Dabei handelt es sich um einen Mechanismus in Websphere, mit dem Sie die SSL-Konfiguration für ein bestimmtes Protokoll, einen bestimmten Host und/oder Port definieren können. So ist es beispielsweise möglich, eine spezifische SSL-Konfiguration für eine HTTPS-Verbindung zu my.hostname.intranet auf 443 und eine weitere für eine HTTPS-Verbindung zu my.other-hostname.intranet zu definieren. In unserem Fall haben wir ein Zertifikat, das den Rechner und nicht so sehr die Anwendung identifiziert, so dass für uns die Einstellung einfach ",,443" lautete: Jedes ausgehende Protokoll zu einem beliebigen Host an Port 443 würde über die konfigurierte SSL-Konfiguration eingerichtet. Was wird also genau in der SSL-Konfiguration eingestellt? In unserem Fall haben wir eine neue SSL-Konfiguration mit einem neuen Schlüsselspeicher (der den privaten Schlüssel und das signierte persönliche Zertifikat enthält) und einem Truststore (der die vertrauenswürdigen Zertifikate der internen Behörde enthält) erstellt. Wir haben auch den Standard-Alias für Client-Zertifikate festgelegt, so dass wir diesen nicht programmatisch einstellen müssen. IBM hat eine Anleitung zur Einrichtung, die vielleicht etwas kompliziert ist, aber gute Informationen über alle Möglichkeiten bietet. Der letzte Schritt bestand darin, unseren Client-Code dazu zu bringen, diese dynamische Outbound-Konfiguration irgendwie zu verwenden. Bei unseren Recherchen im Internet sind wir auf eine Lösung gestoßen, bei der Sie einen ausgehenden Interceptor in die Kette einfügen können, der eine Reihe von Eigenschaften (wie z.B. Host, Port usw.) an eine IBM API weitergibt, die eine SslSocketFactory mit der korrekten SSL-Konfiguration für die Verwendung im Anwendungscode abruft. Dazu muss lediglich der Interceptor in die ausgehende Kette aufgenommen werden, was in der Praxis nur ein paar Zeilen XML in der Spring-Konfiguration erfordert:

<cxf:bus> 
<cxf:outInterceptors> 
<bean class="com.xebia.opensource.cxf.extensions.WebsphereSslOutInterceptor" />
</cxf:outInterceptors> 
</cxf:bus>

Dies setzt die Standard-SSL-Verarbeitung von CXF außer Kraft und ruft die Websphere SSLSocketFactory auf der Grundlage des Hostnamens und des Ports ab, an den die Nachricht gesendet wird. Die Anwendung benötigt keine weitere Konfiguration oder Kenntnisse über Zertifikate. Der Out-Interceptor verursacht auch keine Probleme, wenn er in einem anderen Container (z.B. Jetty) ausgeführt wird oder wenn er sich über einfaches HTTP mit einem Webservice verbindet (in einer Entwicklungsumgebung). In diesen Fällen tut er einfach nichts. Ich habe ein Open Source Maven-Projekt dafür erstellt. Weitere Informationen finden Sie in den Klassen und in der README im Github-Projekt websphere-cxf-extensions. Serverseitige Konfiguration Die serverseitigen Zertifikate enden beim IHS, so dass die Webservice-Anwendung selbst, die die Antwort ausgibt, nichts Besonderes haben muss. Stattdessen wird alles im IHS konfiguriert. Ich gehe davon aus, dass Sie den IHS bereits auf einem SSL-Port laufen lassen und nur sicherstellen müssen, dass nur autorisierte Clients eine Verbindung herstellen können. Um eine Client-Authentifizierung zu verlangen, kann die httpd.conf wie folgt konfiguriert werden: SSLClientAuth required CommonName client.hostname Das bedeutet, dass sich die Clients authentifizieren müssen und nur gültige Zertifikate mit bestimmten allgemeinen Namen (die mit dem Hostnamen des Clients übereinstimmen sollten) Zugang erhalten. Außerdem mussten die öffentlichen Zertifikate der Zertifizierungsstelle zum IHS Truststore hinzugefügt werden, damit der IHS die Client-Zertifikate akzeptiert. Dies war bereits auf den Servern eingerichtet, so dass ich nicht genau weiß, wie man das macht... Fehlerbehebung Es ist schwierig, dies auf Anhieb richtig zu machen, und wenn etwas nicht funktioniert, ist es schwierig, das genaue Problem zu beheben. Wenn Sie versuchen, dies zum Laufen zu bringen, haben uns die folgenden Dinge geholfen:

• Setzen Sie die Protokollierung auf FINEST für die Pakete com.ibm.websphere.ssl.* und com.ibm.ws.ssl.*. Im trace.log haben Sie nun eine Menge Informationen darüber, was in den IBM-Interna vor sich geht.
• Testen Sie, ob das Client-Zertifikat funktioniert, indem Sie zunächst den privaten Schlüssel und das signierte persönliche Zertifikat in Ihren Browser importieren und versuchen, die Verbindung herzustellen. So können Sie herausfinden, ob das Problem auf der Client- oder der Serverseite liegt.