Feature Discussions

[AndreasOesterle]

Bei grossen Unternehmen werden alle Server inklusive des FirstSpirit Server hinter einem Proxy betrieben. Dieser Proxy erfordert häufig eine Authentifizierung.

Beim Start der FirstSpirit Root Web Anwendung sendet der Browser eine Authentifizierung per HTTP Header mit dem Namen Authorization. Als Wert wird übergeben: Basic dHUyNWJwYTp0dTI1YnBh

Beim Start des JavaClients wird dieser HTTP Header leider nicht von der Root Applikation übernommen, so dass die bereits bestehende Basic Authentication verloren geht. Hier wäre es wünschenswert, dass alle HTTP Header die die Web Root Anwendung von dem Browser erhält auch vom JavaClient gesendet werden.

[isenberg]

Für andere Reverse-Proxies mit Authentifizierung basierend auf Cookies wurde bereits der Parameter clientCookieNames für fs-server.conf implementiert, der die von der fs5root-WebApp an den JavaClient weiterzuleitenden Cookies angibt.

Für Reverse-Proxies ohne Cookie-basierte Authentifizierung kann ich mir eine Lösung vorstellen, die z.B. über einen neu zu implementierenden Parameter "clientHttpHeader" die Liste der weiterzuleitenden sonstigen Header angibt. In Ihrem Beispiel wäre das dann clientHttpHeader=Authorization

Diese Headerzeilen würde die fs5root-WebApp über die JNLP-Datei an den JavaClient weitergeben und von diesem anschliessend in der neu aufgebauten http-Verbindung verwendet werden, wie es jetzt bereits bei den Cookies der Fall ist.

Wäre das die benötigte Lösung?

[AndreasOesterle]

Ja, das wäre genau die Lösung!

[isenberg]

Um einen Feature Request daraus zu erstellen, fehlt mir noch ein technisches Detail: Zu welchem Zeitpunkt wird der Authorization-Header gesendet? Klar, beim Aufruf der FirstSpirit-Startseite, aber auch beim Aufruf der JNLP-URL, also http://firstspiritserver.domain/start/FIRSTspirit.jnlp?

Wir würden die Übernahme der http-Header dann aus dem Aufruf der JNLP-URL übernehmen, weil die Header vom Aufruf der Startseite, die möglicherweise zeitlich lange zurückliegt, veraltet sind. Das ginge nur nicht, wenn die JNLP-URL ohne Authentifizierung erreichbar ist, also bewusst im Proxy ohne Authentifizierung freigegeben ist, z.B. weil Java Webstart die Authentifizierung am Proxy nicht durchführen kann.

[AndreasOesterle]

Den Authentication Header vom Aufruf der jnlp Datei zu holen finde ich eine sehr gute Idee.

In unserem Fall ist die URL für die jnlp Datei nicht von der Proxy Authentifizierung ausgeschlossen. Der Java Web Start kann übrigens mit dem Authentication header umgehen. Weil FirstSpirit den Header aktuell noch nicht mitsendet, erscheint ein Popup mit der Eingabe von UserId und Passwort. Wenn ich diese Eingabe 2x korrekt mache, startet der JavaClient hoch. Der JavaClient selbst versucht dann nochmal eine Connection über den Proxy aufzubauen, welche scheitert aufgrund des nicht mitgesendeten Authentication Headers.

[isenberg]

Wäre es möglich, dass Sie in ihrer Proxy-Umgebung einen Test durchführen, ob tatsächlich die statische permanente Übermittlung des einmal ausgelesenen Authorization-Headers in ihrer Umgebung genügt? Dazu z.B. http://www.charlesproxy.com auf dem Client-System installieren und in den benutzerspezifischen Verbindungseinstellungen auf der FirstSpirit-Startseite ins Textfeld "httpproxy=http://localhost:1234" eintragen. 1234 dann durch die Portnummer des Charles-Proxy ersetzen. Den Charles-Proxy konfigurieren, den manuell ausgelesenen Authorization-Header einzufügen bei Aufrufen auf das Request-Pattern "POST /servlet/ClientIO/*", siehe http://www.charlesproxy.com/documentation/tools/rewrite/.

Möglicherweise ist es nämlich erforderlich, während der Benutzer-Sitzung den Inhalt des Authorization-Headers zu aktualisieren, wie es aktuell bereits bei Verwendung des Parameters clientCookieNames gemacht wird.

[AndreasOesterle]

Ich bin derzeit nicht in der Kundenumgebung und habe versucht über eine VPN Verbindung den Test durchzuführen. Leider bekomme ich hier eine seltsame SSLException.

Mein Kollege im Kundennetzwerk kann den Client nicht so leicht installieren, da er keine lokalen Admin Rechte hat um einen Proxy wie Charles zu installieren. Sowas dauert dort leider etwas.

Wahrscheinlich komme ich erst in KW 39 dazu.

Der Authorization Header muss aber auch nicht aktualisiert werden. Bei einer Basic Authentication wird einfach nur der eingebene Username und das Passwort base 64 encoded und dieser String ist damit fix. Auf Wikipedia findet man im Abschnitt basic authentication auch recht gut eine Erklärung: http://de.wikipedia.org/wiki/HTTP-Authentifizierung

[isenberg]

Dieses unschöne Detail des Basic-Auth habe ich wohl verdrängt 🙂 In dem Fall braucht tatsächlich nichts während der Session aktualisiert werden, dafür ist also kein Test notwendig. Allgemein wäre ein Test natürlich schon sicherer, bevor mit der Implementierung begonnen wurde, um zu sehen, ob es noch andere Abhängigkeiten gibt, die wir jetzt nicht bedacht haben. Für den Test mit dem Charles-Proxy im https-Modus muss in den Zertifikatsspeicher der JVM auf Client-Seite das Zertifikat des https-Connectors am Charles  importiert werden oder einfacher, in den FirstSpirit Verbindungseinstellungen eine externe Zertifikatsdatei angeben, wie hier beschrieben:

https://community.e-spirit.com/people/hoebbel/blog/2013/04/18/verwendung-von-openssl-zertifikaten-mi...

[AndreasOesterle]

Das Zertifikat habe ich bereits in den Store importiert. Den Fehler den ich remote habe, hatte ich auch vor Ort bei meinem Kunden nicht. Remote bekomme ich folgenden Fehler im JavaClient angezeigt beim Versuch der fs-client Anwendung sich am Server anzumelden:

Connection problem:javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Diesen Fehler bekomme ich auch wenn ich ohne den Charles versuche mich an dem FS Server zu verbinden.

[isenberg]

Möglicherweise sind also die Parameter für den externen Zertifikatsspeicher (Keystore) auf Clientseite bereits gesetzt und zeigen auf eine nicht vorhandene Datei? Denn laut Google deutet die Fehlermeldung auf Probleme beim Öffnen des Zertifikatsspeicher hin: http://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty

[AndreasOesterle]

Danke für den Hinweis. Ich hatte wohl irgendwie meinen lokalen Zertifikatestore verschossen.

Wenn ich den Zertifikatestore neu setze über die Variable in den Verbindungseinstellungen, dann funktioniert der Connect über den Proxy mit dem JavaClient.

Auch die Maske zur Basic Authentication erscheint nicht mehr wenn ich den Authorization header über den Charles setze, siehe Screenshot:

Mit dem Charles als Proxy zwischendrin ändert sich allerdings auch das Zertifikat und der Charles präsentiert dem JavaClient ein Charles eigenes Zertifikat. Dieses habe ich ebenfalls in den Zertifikatestore importiert und trotzdem erhalte ich folgenden Fehler:

Ich würde den Test aber dennoch als erfolgreich ansehen.

Einen kompletten Test können wir auch leider nicht mehr so leicht durchführen, weil mittlerweile die authentication auf die javaClient Pfade herausgenommen wurde. Es wird derzeit nur noch eine Authentication beim Download der fs-client.jar verlangt.

Reicht ihnen der Test?

Beste Grüsse