Accesso al modulo di sicurezza di primavera

1. Introduzione

Questo articolo si concentrerà sull'accesso con Spring Security . Costruiremo sulla base del semplice esempio precedente di Spring MVC, poiché è una parte necessaria della configurazione dell'applicazione Web insieme al meccanismo di accesso.

2. Le dipendenze di Maven

Quando si lavora con Spring Boot, lo spring-boot-starter-security starter includerà automaticamente tutte le dipendenze come spring-security-core , spring-security-web e spring-security-config tra le altre:

 org.springframework.boot spring-boot-starter-security 2.3.3.RELEASE 

Nel caso in cui non utilizziamo Spring Boot, consultare l'articolo Spring Security with Maven, che descrive come aggiungere tutte le dipendenze richieste. Saranno richiesti sia lo standard spring-security-web che spring-security-config .

3. Configurazione Java Spring Security

Iniziamo creando una classe di configurazione Spring Security che estende WebSecurityConfigurerAdapter.

Aggiungendo @EnableWebSecurity , otteniamo supporto per l'integrazione Spring Security e MVC:

@Configuration @EnableWebSecurity public class SecSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(final AuthenticationManagerBuilder auth) throws Exception { // authentication manager (see below) } @Override protected void configure(final HttpSecurity http) throws Exception { // http builder configurations for authorize requests and form login (see below) } }

In questo esempio, abbiamo utilizzato l'autenticazione in memoria e definito 3 utenti.

Successivamente, esaminiamo gli elementi che abbiamo utilizzato per creare la configurazione di login del modulo.

Costruiamo prima il nostro gestore di autenticazione.

3.1. Gestore dell'autenticazione

Il provider di autenticazione è supportato da una semplice implementazione in memoria, in particolare InMemoryUserDetailsManager . Ciò è utile per la prototipazione rapida quando un meccanismo di persistenza completo non è ancora necessario:

protected void configure(final AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("user1").password(passwordEncoder().encode("user1Pass")).roles("USER") .and() .withUser("user2").password(passwordEncoder().encode("user2Pass")).roles("USER") .and() .withUser("admin").password(passwordEncoder().encode("adminPass")).roles("ADMIN"); }

Qui configuriamo tre utenti con nome utente, password e ruolo codificati.

A partire dalla primavera 5, dobbiamo anche definire un codificatore di password . Nel nostro esempio, abbiamo utilizzato BCryptPasswordEncoder:

@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }

Successivamente, configuriamo HttpSecurity.

3.2. Configurazione per autorizzare le richieste

Iniziamo eseguendo le configurazioni necessarie per autorizzare le richieste.

Qui, stiamo consentendo l'accesso anonimo su / login in modo che gli utenti possano autenticarsi. Limitazione di / admin ai ruoli ADMIN e protezione di tutto il resto:

@Override protected void configure(final HttpSecurity http) throws Exception { http .csrf().disable() .authorizeRequests() .antMatchers("/admin/**").hasRole("ADMIN") .antMatchers("/anonymous*").anonymous() .antMatchers("/login*").permitAll() .anyRequest().authenticated() .and() // ... }

Notare che l'ordine degli elementi antMatchers () è significativo: le regole più specifiche devono essere prima, seguite da quelle più generali .

3.3. Configurazione per l'accesso tramite modulo

Successivamente, estendiamo la configurazione precedente per il login e il logout del modulo:

@Override protected void configure(final HttpSecurity http) throws Exception { http // ... .and() .formLogin() .loginPage("/login.html") .loginProcessingUrl("/perform_login") .defaultSuccessUrl("/homepage.html", true) .failureUrl("/login.html?error=true") .failureHandler(authenticationFailureHandler()) .and() .logout() .logoutUrl("/perform_logout") .deleteCookies("JSESSIONID") .logoutSuccessHandler(logoutSuccessHandler()); }
  • loginPage () - la pagina di accesso personalizzata
  • loginProcessingUrl () - l'URL a cui inviare il nome utente e la password
  • defaultSuccessUrl () - la pagina di destinazione dopo un accesso riuscito
  • failureUrl () - la pagina di destinazione dopo un accesso non riuscito
  • logoutUrl () - il logout personalizzato

4. Aggiungere Spring Security all'applicazione Web

Per utilizzare la configurazione Spring Security sopra definita, è necessario collegarla all'applicazione web.

Useremo WebApplicationInitializer , quindi non è necessario fornire alcun web.xml:

public class AppInitializer implements WebApplicationInitializer { @Override public void onStartup(ServletContext sc) { AnnotationConfigWebApplicationContext root = new AnnotationConfigWebApplicationContext(); root.register(SecSecurityConfig.class); sc.addListener(new ContextLoaderListener(root)); sc.addFilter("securityFilter", new DelegatingFilterProxy("springSecurityFilterChain")) .addMappingForUrlPatterns(null, false, "/*"); } }

Tieni presente che questo inizializzatore non è necessario se utilizziamo un'applicazione Spring Boot. Dai un'occhiata al nostro articolo sulla configurazione automatica della sicurezza Spring Boot per maggiori dettagli su come la configurazione della sicurezza viene caricata in Spring Boot.

5. La configurazione XML di Spring Security

Diamo anche un'occhiata alla configurazione XML corrispondente.

Il progetto generale utilizza la configurazione Java, quindi è necessario importare il file di configurazione XML tramite una classe Java @Configuration :

@Configuration @ImportResource({ "classpath:webSecurityConfig.xml" }) public class SecSecurityConfig { public SecSecurityConfig() { super(); } }

E la configurazione XML di Spring Security - webSecurityConfig.xml :

6. Il file web.xml

Prima dell'introduzione di Spring 4 , eravamo soliti configurare la configurazione di Spring Security nel web.xml - solo un filtro aggiuntivo aggiunto allo standard Spring MVC web.xml :

Spring Secured Application     springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy   springSecurityFilterChain /* 

Il filtro - DelegatingFilterProxy - delega semplicemente a un bean gestito da Spring, il FilterChainProxy , che a sua volta è in grado di trarre vantaggio dalla gestione completa del ciclo di vita del bean Spring e simili.

7. Il modulo di accesso

La pagina del modulo di accesso verrà registrata con Spring MVC utilizzando il meccanismo semplice per mappare i nomi delle visualizzazioni agli URL senza la necessità di un controller esplicito tra:

registry.addViewController("/login.html");

This, of course, corresponds to the login.jsp:


    
User:
Password:

The Spring Login form has the following relevant artifacts:

  • login – the URL where the form is POSTed to trigger the authentication process
  • username – the username
  • password – the password

8. Further Configuring Spring Login

We briefly discussed a few configurations of the login mechanism when we introduced the Spring Security Configuration above – let's go into some detail now.

One reason to override most of the defaults in Spring Security is to hide the fact that the application is secured with Spring Security and minimize the information a potential attacker knows about the application.

Fully configured, the login element looks like this:

@Override protected void configure(HttpSecurity http) throws Exception { http.formLogin() .loginPage("/login.html") .loginProcessingUrl("/perform_login") .defaultSuccessUrl("/homepage.html",true) .failureUrl("/login.html?error=true") }

Or the corresponding XML configuration:

8.1. The Login Page

Next, let's see how we can configure a custom login page using the loginPage() method:

http.formLogin() .loginPage("/login.html")

Or, via XML configuration:

login-page='/login.html'

If we don't specify this, Spring Security will generate a very basic Login Form at the /login URL.

8.2. The POST URL for Login

The default URL where the Spring Login will POST to trigger the authentication process is /login which used to be /j_spring_security_check before Spring Security 4.

We can use the loginProcessingUrl method to override this URL:

http.formLogin() .loginProcessingUrl("/perform_login")

Or, via XML configuration:

login-processing-url="/perform_login"

A good reason to override this default URL is to hide the fact that the application is actually secured with Spring Security – that information should not be available externally.

8.3. The Landing Page on Success

After a successful login process, the user is redirected to a page – which by default is the root of the web application.

We can override this via the defaultSuccessUrl() method:

http.formLogin() .defaultSuccessUrl("/homepage.html")

Or with XML configuration:

default-target-url="/homepage.html"

In case the always-use-default-target is set to true, then the user is always redirected to this page. If that attribute is set to false, then the user will be redirected to the previous page they wanted to visit before being prompted to authenticate.

8.4. The Landing Page on Failure

Same as with the Login Page, the Login Failure Page is autogenerated by Spring Security at /login?error by default.

To override this, we can use the failureUrl() method:

http.formLogin() .failureUrl("/login.html?error=true")

Or with XML:

authentication-failure-url="/login.html?error=true"

9. Conclusion

In questo esempio di accesso Spring , abbiamo configurato un semplice processo di autenticazione: abbiamo discusso il modulo di accesso Spring Security, la configurazione di sicurezza e alcune delle personalizzazioni più avanzate disponibili.

L'implementazione di questo tutorial Spring Login può essere trovata nel progetto GitHub: questo è un progetto basato su Eclipse, quindi dovrebbe essere facile da importare ed eseguire così com'è.

Quando il progetto viene eseguito in locale, è possibile accedere all'HTML di esempio all'indirizzo:

//localhost:8080/spring-security-mvc-login/login.html