streamalism.org

1. Introduktion

Denne artikel vil fokusere på Log ind med Spring Security. Vi skal bygge oven på det enkle tidligere Spring MVC-eksempel, da det er en nødvendig del af opsætningen af ​​webapplikationen sammen med loginmekanismen.

2. Maven-afhængighederne

Når du arbejder med Spring Boot, spring-boot-starter-sikkerhed starter vil automatisk omfatte alle afhængigheder såsom fjeder-sikkerhed-kerne, fjeder-sikkerhed-web og spring-security-config blandt andre:

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

Hvis vi ikke bruger Spring Boot, skal du se artiklen Spring Security with Maven, der beskriver, hvordan du tilføjer alle nødvendige afhængigheder. Begge standarder fjeder-sikkerhed-web og spring-security-config kræves.

3. Spring Security Java-konfiguration

Lad os starte med at oprette en Spring Security-konfigurationsklasse, der udvides WebSecurityConfigurerAdapter.

Ved at tilføje @EnableWebSecurity, vi får support til Spring Security og MVC integration:

@Configuration @EnableWebSecurity offentlig klasse SecSecurityConfig udvider WebSecurityConfigurerAdapter {@Override beskyttet ugyldig konfiguration (endelig AuthenticationManagerBuilder auth) kaster Undtagelse {// godkendelsesmanager (se nedenfor)} @Override beskyttet ugyldig konfiguration (endelig HttpSecurity http // kaste konfiguration http) kast for godkendelsesanmodninger og formular-login (se nedenfor)}}

I dette eksempel har vi brugt autentificering i hukommelsen og defineret 3 brugere.

Dernæst gennemgår vi de elementer, vi har brugt til at oprette konfiguration af formularlogin.

Lad os først bygge vores Authentication Manager.

3.1. Godkendelsesadministrator

Godkendelsesudbyderen understøttes af en simpel implementering i hukommelsen - InMemoryUserDetailsManager specifikt. Dette er nyttigt til hurtig prototyping, når en fuld persistensmekanisme endnu ikke er nødvendig:

beskyttet ugyldig konfiguration (endelig AuthenticationManagerBuilder auth) kaster undtagelse {auth.inMemoryAuthentication () .withUser ("user1"). adgangskode (passwordEncoder (). kodning ("user1Pass")). roller ("USER"). og () .withUser ("bruger2"). adgangskode (passwordEncoder (). kode ("bruger2Pass")). roller ("BRUGER"). og () .withUser ("admin"). adgangskode (passwordEncoder (). indkode ("adminPass") ) .roles ("ADMIN"); }

Her konfigurerer vi tre brugere med brugernavnet, adgangskoden og rollen hårdkodet.

Fra og med Spring 5 skal vi også definere en kodeordskoder. I vores eksempel har vi brugt BCryptPasswordEncoder:

@Bean public PasswordEncoder passwordEncoder () {returner ny BCryptPasswordEncoder (); }

Lad os derefter konfigurere HttpSikkerhed.

3.2. Konfiguration til godkendelse af anmodninger

Vi starter med at udføre de nødvendige konfigurationer for at godkende anmodninger.

Her tillader vi anonym adgang /Log på så brugerne kan godkende. Begrænsende / admin til ADMIN roller og sikring af alt andet:

@ Override beskyttet ugyldig konfiguration (endelig HttpSecurity http) kaster undtagelse {http .csrf (). Deaktiver () .authorizeRequests () .antMatchers ("/ admin / **"). HasRole ("ADMIN") .antMatchers ("/ anonym * "). anonym () .antMatchers (" / login * "). permitAll () .anyRequest (). godkendt () .og () // ...}

Bemærk, at rækkefølgen af antMatchers () elementer er vigtige - jo mere specifikke regler skal komme først efterfulgt af de mere generelle.

3.3. Konfiguration til formular login

Dernæst udvider vi ovenstående konfiguration til formular login og logout:

@ Override beskyttet ugyldig konfiguration (sidste HttpSecurity http) kaster undtagelse {http // ... og () .formLogin () .loginPage ("/ login.html") .loginProcessingUrl ("/ perform_login"). DefaultSuccessUrl ("/ homepage.html ", true) .failureUrl (" / login.html? error = true ") .failureHandler (authenticationFailureHandler ()). og () .logout () .logoutUrl (" / perform_logout ") .deleteCookies (" JSESSIONID " ) .logoutSuccessHandler (logoutSuccessHandler ()); }

• loginPage () - den brugerdefinerede login-side
• loginProcessingUrl () - URL'en, som brugernavnet og adgangskoden skal sendes til
• defaultSuccessUrl () - destinationssiden efter et vellykket login
• failureUrl () - landingssiden efter et mislykket login
• logoutUrl () - den brugerdefinerede logout

4. Føj forårssikkerhed til webapplikationen

For at bruge den ovenfor definerede Spring Security-konfiguration skal vi vedhæfte den til webapplikationen.

Vi bruger WebApplicationInitializer, så vi behøver ikke give nogen web.xml:

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

Bemærk, at denne initialisering ikke er nødvendig, hvis vi bruger en Spring Boot-applikation. Se vores artikel om Spring Boot sikkerhed automatisk konfiguration for flere detaljer om, hvordan sikkerhedskonfigurationen indlæses i Spring Boot.

5. Spring Security XML-konfiguration

Lad os også se på den tilsvarende XML-konfiguration.

Det samlede projekt bruger Java-konfiguration, så vi skal importere XML-konfigurationsfilen via en Java @Konfiguration klasse:

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

Og XML-konfigurationen for forårssikkerhed - webSecurityConfig.xml:

6. Den web.xml

Før introduktionen af ​​forår 4, vi plejede at konfigurere Spring Security-konfiguration i web.xml - kun et ekstra filter tilføjet til standard Spring MVC web.xml:

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

Filteret - DelegeringFilterProxy - delegerer simpelthen til en forårsledet bønne - den FilterChainProxy - som selv er i stand til at drage fordel af fuld Spring Bean Lifecycle Management og sådan.

7. Loginformularen

Loginformularens side bliver registreret hos Spring MVC ved hjælp af den enkle mekanisme til at kortlægge visningsnavne til URL'er uden behov for en eksplicit controller i mellem:

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

Dette svarer naturligvis til login.jsp:

Bruger:
Adgangskode:

Det Spring Login formular har følgende relevante artefakter:

• Log på - den URL, hvor formularen POSTES for at udløse godkendelsesprocessen
• brugernavn - brugernavnet
• adgangskode - adgangskoden

8. Yderligere konfiguration af forårets login

Vi diskuterede kort et par konfigurationer af loginmekanismen, da vi introducerede Spring Security Configuration ovenfor - lad os gå ind i nogle detaljer nu.

En grund til at tilsidesætte de fleste af standarderne i Spring Security er at skjul det faktum, at applikationen er sikret med Spring Security og minimer de oplysninger, som en potentiel angriber kender til applikationen.

Fuldt konfigureret ser loginelementet sådan ud:

@ Override beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.formLogin () .loginPage ("/ login.html") .loginProcessingUrl ("/ perform_login") .defaultSuccessUrl ("/ homepage.html", true) .failureUrl ( "/login.html?error=true")}

Eller den tilsvarende XML-konfiguration:

8.1. Login siden

Lad os derefter se, hvordan vi kan konfigurere en brugerdefineret login-side ved hjælp af loginPage () metode:

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

Eller via XML-konfiguration:

login-side = '/ login.html'

Hvis vi ikke specificerer dette, genererer Spring Security en meget grundlæggende loginformular på /Log på URL.

8.2. POST-URL til login

Standard-URL'en, hvor Spring Login vil POST for at udløse godkendelsesprocessen, er /Log på som plejede at være / j_spring_security_check inden forårssikkerhed 4.

Vi kan bruge loginProcessingUrl metode til at tilsidesætte denne URL:

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

Eller via XML-konfiguration:

login-processing-url = "/ perform_login"

En god grund til at tilsidesætte denne standard-URL er at skjule det faktum, at applikationen faktisk er sikret med Spring Security - disse oplysninger bør ikke være tilgængelige eksternt.

8.3. Landingssiden om succes

Efter en vellykket loginproces omdirigeres brugeren til en side - som standard er roden til webapplikationen.

Vi kan tilsidesætte dette via defaultSuccessUrl () metode:

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

Eller med XML-konfiguration:

standard-mål-url = "/ startside.html"

I tilfælde af at brug altid-standard-mål er sat til sand, så omdirigeres brugeren altid til denne side. Hvis denne attribut er indstillet til falsk, omdirigeres brugeren til den forrige side, de ønskede at besøge, før han blev bedt om at godkende.

8.4. Landingssiden ved fiasko

Samme som med login-siden, oprettes loginfejlsiden automatisk af Spring Security kl /Log på?fejl som standard.

For at tilsidesætte dette kan vi bruge failureUrl () metode:

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

Eller med XML:

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

9. Konklusion

Heri Eksempel på forårets login, vi konfigurerede en simpel godkendelsesproces - vi diskuterede Spring Security Login-formularen, sikkerhedskonfigurationen og nogle af de mere avancerede tilpasninger, der er tilgængelige.

Implementeringen af ​​denne Spring Login-tutorial kan findes i GitHub-projektet - dette er et Eclipse-baseret projekt, så det skal være let at importere og køre, som det er.

Når projektet kører lokalt, kan du få adgang til HTML-eksemplet på:

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