streamalism.org

1. Introduksjon

Denne artikkelen kommer til å fokusere på Logg inn med Spring Security. Vi kommer til å bygge på det enkle forrige Spring MVC-eksemplet, da det er en nødvendig del av å konfigurere webapplikasjonen sammen med påloggingsmekanismen.

2. Maven-avhengighetene

Når du arbeider med Spring Boot, vår-boot-starter-sikkerhet starter vil automatisk inkludere alle avhengigheter som vår-sikkerhetskjerne, vår-sikkerhets-web og vår-sikkerhet-config blant andre:

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

Hvis vi ikke bruker Spring Boot, kan du se artikkelen om Spring Security with Maven, som beskriver hvordan du legger til alle nødvendige avhengigheter. Begge standardene vår-sikkerhets-web og vår-sikkerhet-config vil være påkrevd.

3. Vårsikkerhet Java-konfigurasjon

La oss starte med å opprette en Spring Security-konfigurasjonsklasse som utvides WebSecurityConfigurerAdapter.

Ved å legge til @EnableWebSecurity, får vi vårsikkerhets- og MVC-integreringsstøtte:

@Configuration @EnableWebSecurity offentlig klasse SecSecurityConfig utvider WebSecurityConfigurerAdapter {@Override-beskyttet ugyldig konfigurering (endelig AuthenticationManagerBuilder auth) kaster Unntak {// autentiseringsbehandling (se nedenfor)} @Override beskyttet ugyldig konfigurering (endelig HttpSecurity http) kast for godkjenningsforespørsler og skjemainnlogging (se nedenfor)}}

I dette eksemplet har vi brukt autentisering i minnet og definert 3 brukere.

Deretter går vi gjennom elementene vi har brukt til å lage innloggingskonfigurasjonen for skjemaet.

La oss først bygge vår Authentication Manager.

3.1. Autentiseringsleder

Autentiseringsleverandøren støttes av en enkel implementering i minnet - InMemoryUserDetailsManager nærmere bestemt. Dette er nyttig for rask prototyping når en full utholdenhetsmekanisme ennå ikke er nødvendig:

beskyttet ugyldig konfigurasjon (endelig AuthenticationManagerBuilder auth) kaster unntak {auth.inMemoryAuthentication () .withUser ("user1"). passord (passwordEncoder (). encode ("user1Pass")). roller ("USER"). og () .withUser ("user2"). passord (passwordEncoder (). koding ("user2Pass")). roller ("USER"). og () .withUser ("admin"). passord (passwordEncoder (). encode ("adminPass") ) .roles ("ADMIN"); }

Her konfigurerer vi tre brukere med brukernavn, passord og rolle hardkodet.

Fra og med våren 5 må vi også definere en passordkoder. I vårt eksempel har vi brukt BCryptPasswordEncoder:

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

Deretter la oss konfigurere HttpSikkerhet.

3.2. Konfigurasjon for å autorisere forespørsler

Vi starter med å gjøre de nødvendige konfigurasjonene for å autorisere forespørsler.

Her tillater vi anonym tilgang /Logg Inn slik at brukerne kan autentisere. Begrensende / admin til ADMIN roller og sikre alt annet:

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

Merk at rekkefølgen på antMatchers () elementer er viktig - jo mer spesifikke regler må komme først, etterfulgt av de mer generelle.

3.3. Konfigurasjon for skjemainnlogging

Deretter utvider vi konfigurasjonen ovenfor for innlogging og utlogging av skjema:

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

• loginPage () - den tilpassede påloggingssiden
• loginProcessingUrl () - URLen du skal sende brukernavnet og passordet til
• defaultSuccessUrl () - destinasjonssiden etter vellykket pålogging
• failureUrl () - destinasjonssiden etter mislykket pålogging
• logoutUrl () - den tilpassede utloggingen

4. Legg til vårsikkerhet i webapplikasjonen

For å bruke den ovenfor definerte Spring Security-konfigurasjonen, må vi legge den til webapplikasjonen.

Vi bruker WebApplicationInitializer, så vi trenger ikke å oppgi noe web.xml:

offentlig klasse 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, "/ *"); }}

Merk at denne initialisereren ikke er nødvendig hvis vi bruker en Spring Boot-applikasjon. Ta en titt på artikkelen vår om automatisk konfigurasjon av Spring Boot-sikkerhet for mer informasjon om hvordan sikkerhetskonfigurasjonen er lastet inn i Spring Boot.

5. XML-konfigurasjonen for vårsikkerhet

La oss også ta en titt på den tilsvarende XML-konfigurasjonen.

Det samlede prosjektet bruker Java-konfigurasjon, så vi må importere XML-konfigurasjonsfilen via en Java @Konfigurasjon klasse:

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

Og XML-konfigurasjonen for vårsikkerhet - webSecurityConfig.xml:

6. Den web.xml

Før introduksjonen av våren 4, vi pleide å konfigurere vårsikkerhetskonfigurasjon i web.xml - bare et ekstra filter lagt til standard Spring MVC web.xml:

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

Filteret - DelegeringFilterProxy - bare delegerer til en vårstyrt bønne - the FilterChainProxy - som i seg selv er i stand til å dra nytte av full vårsyklusadministrasjon og slikt.

7. Påloggingsskjemaet

Påloggingsskjema-siden skal registreres hos Spring MVC ved å bruke den enkle mekanismen for å kartlegge visningsnavn til URL-er uten behov for en eksplisitt kontroller i mellom:

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

Dette tilsvarer selvfølgelig innlogging.jsp:

Bruker:
Passord:

De Vårinnloggingsskjema har følgende relevante gjenstander:

• Logg Inn - nettadressen der skjemaet POSTES for å utløse godkjenningsprosessen
• brukernavn - brukernavnet
• passord - passordet

8. Ytterligere konfigurering av vårinnlogging

Vi diskuterte kort noen få konfigurasjoner av påloggingsmekanismen da vi introduserte Spring Security Configuration ovenfor - la oss gå i detalj.

En grunn til å overstyre de fleste av standardene i Spring Security er å skjul det faktum at applikasjonen er sikret med Spring Security og minimer informasjonen en potensiell angriper vet om applikasjonen.

Fullt konfigurert ser påloggingselementet slik ut:

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

Eller tilsvarende XML-konfigurasjon:

8.1. Påloggingssiden

La oss deretter se hvordan vi kan konfigurere en tilpasset påloggingsside ved hjelp av loginPage () metode:

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

Eller via XML-konfigurasjon:

innloggingsside = '/ login.html'

Hvis vi ikke spesifiserer dette, vil Spring Security generere et veldig grunnleggende påloggingsskjema på /Logg Inn URL.

8.2. POST-URL-en for pålogging

Standard URL der vårinnloggingen POSTER for å utløse godkjenningsprosessen er /Logg Inn som pleide å være / j_spring_security_check før vårsikkerhet 4.

Vi kan bruke loginProcessingUrl metode for å overstyre denne URL:

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

Eller via XML-konfigurasjon:

login-processing-url = "/ perform_login"

En god grunn til å overstyre denne standard URL-en er å skjule det faktum at applikasjonen faktisk er sikret med Spring Security - at informasjonen ikke skal være tilgjengelig eksternt.

8.3. Landingssiden om suksess

Etter en vellykket påloggingsprosess blir brukeren omdirigert til en side - som standard er roten til webapplikasjonen.

Vi kan overstyre dette via defaultSuccessUrl () metode:

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

Eller med XML-konfigurasjon:

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

I tilfelle bruk alltid standardmål er satt til sann, blir brukeren alltid omdirigert til denne siden. Hvis denne attributtet er satt til false, vil brukeren bli omdirigert til forrige side de ønsket å besøke før han ble bedt om å godkjenne.

8.4. Landingssiden på feil

Samme som med påloggingssiden, blir innloggingsfeil siden autogenerert av Spring Security kl /Logg Inn?feil som standard.

For å overstyre dette kan vi bruke failureUrl () metode:

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

Eller med XML:

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

9. Konklusjon

I dette Eksempel på vårinnlogging, konfigurerte vi en enkel autentiseringsprosess - vi diskuterte Spring Security Login Form, Security Configuration og noen av de mer avanserte tilpasningene som er tilgjengelige.

Implementeringen av våropplæringsveiledningen finner du i GitHub-prosjektet - dette er et formørkelsesbasert prosjekt, så det skal være enkelt å importere og kjøre som det er.

Når prosjektet kjøres lokalt, kan du få tilgang til HTML-eksemplet på:

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