Spring Security - sicurezza nessuno, filtri nessuno, permesso di accesso Tutti

1. Panoramica

Spring Security fornisce diversi meccanismi per configurare un pattern di richiesta come non protetto o per consentire tutti gli accessi. A seconda di ciascuno di questi meccanismi, ciò può significare non eseguire affatto la catena di filtri di sicurezza su quel percorso o eseguire la catena di filtri e consentire l'accesso.

2. access = "allowAll"

Creazione di un file elemento con access = "allowAll" configurerà l'autorizzazione in modo che tutte le richieste siano consentite su quel particolare percorso:

Oppure, tramite la configurazione Java:

http.authorizeRequests().antMatchers("/login*").permitAll();

Ciò si ottiene senza disabilitare i filtri di sicurezza : questi sono ancora in esecuzione, quindi qualsiasi funzionalità relativa a Spring Security sarà ancora disponibile.

3. filtri = "nessuno"

Questa è una funzionalità pre-Spring 3.1 che è stata deprecata e sostituita in Spring 3.1.

L' attributo filtri disabilita la catena dei filtri Spring Security interamente su quel particolare percorso di richiesta:

Ciò potrebbe causare problemi quando l'elaborazione della richiesta richiederà alcune funzionalità di Spring Security.

Poiché si tratta di una funzionalità deprecata, le versioni di Spring più recenti della 3.0, utilizzandola con Spring 3.1 si verificherà un'eccezione di runtime all'avvio:

SEVERE: Context initialization failed org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: The use of "filters='none'" is no longer supported. Please define a separate  element for the pattern you want to exclude and use the attribute "security='none'". Offending resource: class path resource [webSecurityConfig.xml] at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)

4. security = "none"

Come abbiamo visto nel messaggio di errore sopra, Spring 3.1 sostituisce i filtri = "none" con una nuova espressione - security = "none" .

Anche l'ambito è cambiato: non è più specificato in livello di elemento. Invece, Spring 3.1 consente piùelementi da definire, ciascuno con la propria configurazione della catena di filtri di sicurezza. E così, il nuovo attributo di sicurezza ora appartiene a livello di elemento.

In pratica, questo sarà simile a:

O con la configurazione Java:

web.ignoring().antMatchers("/resources/**");

Invece del vecchio:

Simile a filters = "none" , questo disabiliterà completamente anche la catena di filtri di sicurezza per quel percorso di richiesta, quindi quando la richiesta viene gestita nell'applicazione, le funzionalità di Spring Security non saranno disponibili.

Questo non è un problema per gli esempi precedenti, che trattano principalmente di servire risorse statiche - dove non ha luogo alcuna elaborazione effettiva. Tuttavia, se la richiesta viene gestita a livello di codice in qualche modo, le funzionalità di sicurezza come require-channel , l'accesso all'utente corrente o la chiamata di metodi protetti non saranno disponibili.

Per lo stesso motivo, non ha senso specificare attributi aggiuntivi su un file elemento che è già stato configurato con security = "none" perché il percorso della richiesta non è protetto e gli attributi verranno semplicemente ignorati.

In alternativa, è possibile utilizzare access = 'IS_AUTHENTICATED_ANONYMOUSLY' per consentire l'accesso anonimo.

5. Avvertenze per la sicurezza = "nessuno"

Quando si utilizzano più file elementi, alcuni configurati con security = "none" , tieni presente che l'ordine in cui questi elementi sono definiti è importante. Vogliamo avere lo specifico prima i percorsi, seguito lo schema universale alla fine.

Si noti inoltre che, se un file elemento non specifica un modello , quindi per impostazione predefinita, che mappa al modello di corrispondenza universale - "/ **" - quindi, ancora una volta, questo elemento deve essere l'ultimo. Se l'ordine degli elementi non è corretto, la creazione della catena di filtri di sicurezza fallirà :

Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**') is defined before other patterns in the filter chain, causing them to be ignored. Please check the ordering in your  namespace or FilterChainProxy bean configuration at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49) at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)

6. Conclusione

Questo articolo discute le opzioni per consentire l'accesso a un percorso con Spring Security, concentrandosi sulle differenze tra filtri = "none", security = "none" e access = "allowAll" .

Come al solito, gli esempi sono disponibili su GitHub.