2013-08-08 26 views
5

So che questo è già stato chiesto, ma non riesco a farlo funzionare. Ecco cosa mi piacerebbe ottenere compiuto:Spring Security 3.2 Autenticazione token

Sto utilizzando Spring Security 3.2 per garantire un servizio simile a REST. Nessuna sessione lato server. Non sto utilizzando l'autenticazione di base, perché ciò significherebbe che ho bisogno di memorizzare la password dell'utente in un cookie sul lato client. In caso contrario, l'utente dovrebbe effettuare il login con ogni pagina di aggiornamento/modifica. Memorizzando un token penso che sia il male minore.

  1. un web client (browser, app mobile) chiama un URL REST simile al login "/ login" con nome utente e password
  2. Il server autentica l'utente e invia un token al client
  3. il client memorizza il token e lo aggiunge l'intestazione della richiesta HTTP con ogni chiamata API
  4. il server verifica la validità del token e invia una risposta di conseguenza

non ho nemmeno guardato la parte del token generazione ancora . So che è a ritroso, ma volevo ottenere la parte di validazione del token implementata per prima.

Sto cercando di ottenere questo risultato utilizzando un filer personalizzato (implementazione di AbstractAuthenticationProcessingFilter), tuttavia mi sembra di avere l'idea sbagliata.

Definire in questo modo:

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

farà scattare solo il filtro per questo URL esatto. Mi attengo ad alcune implementazioni di esempio, dove chiama AbstractAuthenticationProcessingFilter # requiresAuthentication che non accetta i caratteri jolly. Posso ovviamente modificare quel comportamento, ma questo in qualche modo mi fa pensare che sono sulla strada sbagliata.

Ho anche iniziato a implementare un AuthenticationProvider personalizzato. Forse è la cosa giusta? Qualcuno può darmi una spinta nella giusta direzione?

+1

Io cerco di fare esattamente la stessa cosa .. hai avuto successo con la sicurezza di primavera? puoi per favore dettagliare la tua soluzione? – fvisticot

+0

Hai trovato una soluzione? – sinu

risposta

1

Penso che il filtro pre-autorizzazione sia più adatto per il tuo scenario. Sovrascrivi i metodi getPrincipal e getCredentials di AbstractPreAuthenticatedProcessingFilter. Nel caso in cui il token non sia presente nell'intestazione, restituisce null da getPrincipal.

Flusso:

  • utente accede per la prima volta, alcuna intestazione passato, quindi nessun oggetto di autenticazione impostato in SecurityContext, normale processo di autenticazione segue filtro cioè ExceptionTranslation redirtects all'utente a/login pagina in base al filtro di accesso modulo o all'autenticazione personalizzataEntryPoint
  • Dopo l'autenticazione riuscita, l'utente richiede l'URL protetto, il filtro di pre-autorizzazione ottiene il token dall'oggetto di autenticazione dell'intestazione impostato in securityC ontext, se l'utente ha accesso è autorizzato ad accedere all'url
Problemi correlati