Pre-shared key Authentifizierung mit Spring Boot

Pre-Shared Keys sind mit Spring Boot eine Geschichte voller Missverständnisse. Hier jeweils meine:

HTTP/HTTPS

In der Theorie scheint die Verwendung von https “überflüssig”, denn wenn ich eh nur vorher als “vertrauenswürdig” zertifizierte Clients zulasse, warum dann noch die Verbindung absichern. Naheliegende Antwort: Austausch von Identitäten über http ist nie gut – ⚠

Also https in den application.properties (/application.yml) der Server-Anwendung einschalten:

Zertifikatserstellung

Die eigentliche Idee ist jetzt: Jeder Client muss ein “trusted” Zertifikat vorweisen. Diese Zertifikate werden in einem “Trust-Store” abgelegt, den der Server bekommt. Der Client bekommt sein Zertifikat ebenfalls, dort in einem “Key-Store”, um sich auszuweisen. Andersrum analog: Das Serverzertifikat bekommt der Client in einem Trust-Store, um den https-Server zu verifizieren, der Server legt das in seinem Key-Store ab.

Insgesamt sieht die Erstellung so aus:

Wichtig dabei: Die verwendeten Passwörter (klar), aber auch der verwendete Name, beides brauchen wir unten.

PS, siehe unten und hier

Zertifikate einbinden

Die Zertifikate kann man dem Server jetzt über einen TomcatConnector bekannt machen, muss man in Spring Boot aber nicht (⚠; Danke, Nils). Stattdessen genügt Folgendes, ebenfalls in den application.properties:

Hier verweise ich auf Key-Stores in der .jar, was seit Tomcat 7.0.66+ funktioniert. ⚠

In der Client-Anwendung sieht das etwas anders aus, zuerst die application.properties:

Verwendung dann beispielhaft in einem RestTemplate (org.apache.http.* gibt’s hier)

ACHTUNG: Der NoopHostnameVerifier war hier nötig, da ich das Zertifikat nicht mit expliziten Hostnames erstellt habe, in Production würde man das wohl tun. ⚠

Userverwaltung

Natürlich kann man mehrere Client-Zertifikate verwenden, und natürlich kann man jedem Client separate Rechte zuweisen. In der Server-Anwendung:

(Quelle und Stack Overflow)

btw: Spring Security bringt einen default User mit (“user”, Passwort wird auf der Konsole beim Hochfahren ausgegeben). Deaktivierung in den application.properties:

hth

Spring Boot Security: 403 Forbidden

Es gibt durchaus gute Tutorials und Examples für Spring Boot Security. Nur benutzen die alle Thymeleaf als Templating Engine. Und Thymeleaf hat eine Besonderheit: Wenn man im Form “th:action” statt “action” verwendet, dann wird automatisch ein hidden Input Field mit dem CSRF-Token injected!

Wenn man stattdessen bsplw. Velocity verwendet, und das Template 1:1 übersetzt, merkt man nicht, dass etwas fehlt m( Der Server gibt “403 Forbidden” ohne weitere Fehlermeldung zurück (Tipp zum Debuggen: Der Request wird irgendwann auf die Error-Route umgebogen, aber der Fehler (hier noch inklusive Fehlermeldung) steht im Response-Object).

Offenbar muss man den Token dann manuell dem Template übergeben (Quelle, weicht aber leicht ab):

Gegenprobe:

Update

Übrigens: Hier wird beschrieben, wie man in Thymeleaf den Token in jeden Ajax-Request bekommt. Leider funktioniert das so nicht, denn um den Platzhalter zu ersetzen, muss man th:content verwenden (Quelle indirekt), sonst wird der Platzhalter nicht ausgewertet m(

Dann: Siehe hier für das Absetzen der Requests (in jQuery oder Angular)

PHPIDS, WPIDS

php

Auf PHPIDS bin ich in der c’t 10/2009 (S. 164 ff) gestoßen. Es geht um ein PHP-Script, das, in alle öffentlich zugänglichen Scripte einer Webseite eingebunden, Einbruchsversuche erkennen soll. Diese werden dann geratet, und der Webmaster im Zweifelsfalls per Email informiert. Klingt erstmal gut, vor allem aus folgenden Gründen:

  • Neuerdings werden Email-Benachrichtigungen über neue Kommentare hier im Blog nicht mehr zugestellt. OK, sie gehen an die Absenderadresse zurück, die ebenfalls meine ist, aber eben sehr verzögert. Fehlermeldung: “Too many bad recipients, are you an address harvester?” Vielleicht werden von meinem Server aus SPAM-Mails verschickt? Vielleicht auch nicht. Da es nur ein virtueller Server ist, muss es nicht mal “mein” Server sein, wer weiß.
  • Es gibt das Ganze auch als WordPress-Plugin 🙂

Das Dumme an diesem Plugin: So lange es aktiviert ist, geht der Bilder-Upload nicht mehr, Fehlermeldung (sinngemäß aus dem Gedächtnis): “Are you sure you want to do this? Try again”; der angebotene Link führt dann aber aus dem Backend auf den eigentlichen Blog. So viel dazu.

PS: WordPress Version 2.7.1, WPIDS 0.1.2