Spring Security 3.2 Token Authentifizierung

Question

Ich weiß, dass dies schon gefragt wurde, aber ich bin nicht in der Lage, es zur Arbeit zu bekommen. Folgendes möchte ich erreichen:

Ich verwende Spring Security 3.2, um einen REST-ähnlichen Dienst zu sichern. Keine serverseitigen Sitzungen. Ich benutze keine Basic Auth, da dies bedeuten würde, dass ich das Passwort des Benutzers in einem Cookie auf der Client-Seite speichern muss. Andernfalls müsste sich der Benutzer bei jeder Aktualisierung/Änderung der Seite anmelden. Ein Token zu speichern ist das kleinere Übel.

1. Ein Web-Client (Browser, mobile app) ruft eine REST-ähnliche URL anmelden "/ login" mit Benutzername und Passwort
2. Der Server der Benutzer authentifiziert und sendet ein Token an den Client zurück
3. der Client speichert das Token und fügt sie die hTTP-Request-Header mit jedem aPI-Aufruf
4. der Server überprüft die Gültigkeit des Tokens und sendet eine Antwort entsprechend

ich an dem Token-Erzeugungs-Teil noch nicht einmal aussehen . Ich weiß, dass es rückwärts ist, aber ich wollte den Token-Validierungsteil zuerst implementieren lassen.

Ich versuche, dies mit einem benutzerdefinierten Filer (Implementierung von AbstractAuthenticationProcessingFilter) erreicht, aber ich habe anscheinend die falsche Vorstellung davon.

es wie folgt definieren:

public TokenAuthenticationFilter() { 
    super("/"); 
} 

nur die Filter für diese genaue URL auslösen. Ich halte an einer Beispielimplementierung fest, in der AbstractAuthenticationProcessingFilter # requiresAuthentication aufgerufen wird, die keine Platzhalter akzeptiert. Ich kann natürlich dieses Verhalten ändern, aber das bringt mich irgendwie dazu zu denken, dass ich auf dem falschen Weg bin.

Ich begann auch, einen benutzerdefinierten AuthenticationProvider zu implementieren. Vielleicht ist das das Richtige? Kann mir jemand in die richtige Richtung gehen?

Answer 1

Ich denke, Pre-Auth-Filter ist eine bessere Lösung für Ihr Szenario. Überschreiben Sie die Methoden getPrincipal und getCredentials von AbstractPreAuthenticatedProcessingFilter. Wenn das Token nicht im Header vorhanden ist, geben Sie null von getPrincipal zurück.

Fluss:

• Benutzer anmeldet zum ersten Mal kein Header weitergegeben, so dass keine Objekt Authentifizierung festgelegt in Security, normale Authentifizierung Prozess folgt Filter dh ExceptionTranslation redirtects den Benutzer zu/Login Seite basierend auf Formular-Anmeldefilter oder Ihre benutzerdefinierte AuthentifizierungEntryPoint
• Nach erfolgreicher Authentifizierung, Benutzer Anforderungen gesicherte URL, Pre-Auth-Filter ruft Token von Header-Authentifizierung Objekt in SecurityC festgelegt ontext, wenn der Benutzer Zugriff hat, darf er auf die gesicherte Adresse zugreifen url