Spring Security, Customizing Authorization, AccessDecisionManager vs Security Filter

Question

Implementerò un'autorizzazione personalizzata basata sul modello ([Utente < -> Ruolo < -> Diritto]) e Diritti dovrebbero essere confrontati con il nome del controller e del metodo (ad esempio "controller | metodo").

ho usato UserDetails personalizzazione e AuthenticationProvider per regolare delega conferita (here), ma come controllare i codici sorgente e documentazione su come la personalizzazione del confronto di autorità ho trovato c'è un filtro SecurityContextHolderAwareRequestWrapper) che implementa isGranted e IsUserInRole per confrontare l'autorità, mentre i documenti dicono usando gli elettori di AccessDecisionManager per personalizzare (come ho capito). Quale dovrebbe essere usato? Dove ho il nome del controller e del metodo (azione) per confrontare l'autorità con loro?

Mi sono un po 'confuso riguardo la sicurezza di Spring. C'è qualche altra risorsa rispetto ai documenti ufficiali che illustrano come funziona, intendo sequenza di azioni e metodi e come personalizzarli.

Answer 1

Ci sono diversi approcci:

1. Role Based, in cui si assegna ad ogni utente un ruolo e verificare il ruolo prima di procedere
2. Utilizzo di espressioni di sicurezza a molla
3. C'è anche un nuovi componenti primavera ACL che consente di eseguire il controllo ACL a livello di classe e vengono memorizzati in un database. Il mio utilizzo personale finora è stato 1 e 2, in cui si assegnano solo ruoli agli utenti. Ma l'opzione 3 consente di creare modello di sicurezza più sofistica, senza dover ricostruire il vostro webapp quando chaning il modello di sicurezza

Role Based

un meccanismo di sicurezza basato sul ruolo può essere realizzato implementando l'interfaccia UserDetailsService e configurare la sicurezza di primavera per utilizzare questa classe.

Per imparare su come un tale progetto può essere realizzato, date un'occhiata ai seguenti esercitazioni: login basato

• form con un database utente memoria Link login basato
• form con UserDetails personalizzati servizio Link

In primavera la sicurezza breve esegue le seguenti dietro le quinte:

1. Dopo l'autenticazione (ad es. invio di un modulo di accesso) viene creato un oggetto di autenticazione che contiene le credenziali di accesso. Ad esempio il UsernamePasswordAuthenticationFilter crea un UsernamePasswordAuthenticationToken
2. L'oggetto di autenticazione viene passato a un AuthenticationManager, che può essere considerato il controller nel processo di autenticazione. L'implementazione predefinita è ProviderManager
3. AuthenticationManager esegue l'autenticazione tramite AuthenticationProvider. L'implementazione predefinita utilizzata è DaoAuthenticationProvider.
4. DaoAuthenticationProvider esegue l'autenticazione recuperando UserDetails da UserDetailsService.UserDetails può essere pensato come un oggetto dati che contiene le credenziali dell'utente, ma anche le autorità/i ruoli dell'utente! DaoAuthenticationProvider recupera le credenziali tramite il suo metodo loadUserByUsername e quindi lo confronta con UsernamePasswordAuthenticationToken fornito.
5. UserDetailsService raccoglie le credenziali dell'utente, le autorizzazioni e crea un oggetto UserDetails al di fuori di esso. Ad esempio è possibile recuperare un hash di password e le autorità da un database. Quando si configurano i modelli di URL del sito Web, è possibile fare riferimento alle autorità nell'accesso attribute. Inoltre, è possibile recuperare l'oggetto Autenticazione nelle classi del controllore tramite SecurityContextHolder.getContext(). GetAuthentication().

Furthemore per ottenere una migliore comprensione del funzionamento interno di queste classi è possibile leggere le javadocs:

• UserDetails - come le credenziali dell'utente sono memorizzati e accessibili
• AuthenticationManager.authenticate(..) - contratto su come AuthenticationExceptions sono gestiti
• UserDetailsService.loadUserByUsername(..) - contatto su come vengono gestiti gli errori di ricerca dei nomi utente, ad es. utente non esiste

Spel

Invece di autorità di controllo, SPEL vi permette anche di controllare altre proprietà di un utente. È possibile utilizzarli nei pattern URL, ma anche annotare i metodi con @Preauthorize. In questo modo la protezione del livello aziendale è meno invadente.

ACL base

modello basato L'ACL è stata introdotta in primavera la sicurezza 3.0, ma non è stato ben documented. Il loro suggerimento è di guardare allo Contacts XML example, poiché questo usa il loro nuovo componente acl.

Ultimo this book contiene ottimi esempi su come personalizzare ulteriormente i vostri desideri di sicurezza.