Spring Boot Security Auto-Configuration

1. Introduksjon

I denne artikkelen vil vi se på Spring Boots meningsfulle tilnærming til sikkerhet.

Enkelt sagt, vi skal fokusere på standard sikkerhetskonfigurasjon og hvordan vi kan deaktivere eller tilpasse den hvis vi trenger det.

2. Standard sikkerhetsoppsett

For å legge til sikkerhet i vår Spring Boot-applikasjon, må vi legge til sikkerhetsstarteravhengighet:

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

Dette vil inkludere SecurityAutoConfiguration klasse - som inneholder den innledende / standard sikkerhetskonfigurasjonen.

Legg merke til hvordan vi ikke spesifiserte versjonen her, med forutsetningen om at prosjektet allerede bruker Boot som overordnet.

For å si det enkelt, Autentisering blir som standard aktivert for applikasjonen. Innholdsforhandlinger brukes også til å avgjøre om basic eller formLogin skal brukes.

Det er noen forhåndsdefinerte egenskaper, for eksempel:

spring.security.user.name spring.security.user.password

Hvis vi ikke konfigurerer passordet ved hjelp av den forhåndsdefinerte egenskapen vår.sikkerhet.bruker.passord og starter applikasjonen, vil vi legge merke til at et standardpassord genereres tilfeldig og skrives ut i konsolloggen:

Bruker standard sikkerhetspassord: c8be15de-4488-4490-9dc6-fab3f91435c6

For flere standardinnstillinger, se sikkerhetsegenskapene på referansesiden for Spring Boot Common Application Properties.

3. Deaktivering av autokonfigurasjon

For å forkaste den automatiske sikkerhetskonfigurasjonen og legge til vår egen konfigurasjon, må vi ekskludere SecurityAutoConfiguration klasse.

Dette kan gjøres via en enkel utelukkelse:

@SpringBootApplication (ekskluder = {SecurityAutoConfiguration.class}) offentlig klasse SpringBootSecurityApplication {offentlig statisk ugyldig hoved (String [] args) {SpringApplication.run (SpringBootSecurityApplication.class, args); }} 

Eller ved å legge til noen konfigurasjoner i application.properties fil:

spring.autoconfigure.exclude = org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration

Det er også noen spesielle tilfeller der dette oppsettet ikke er helt nok.

For eksempel startes nesten hver Spring Boot-applikasjon med aktuator i klassestien. Dette skaper problemer fordi en annen automatisk konfigurasjonsklasse trenger den vi nettopp har ekskludert, slik at applikasjonen ikke starter.

For å løse dette problemet, må vi ekskludere den klassen; og, spesifikt for aktuatorsituasjonen, må vi ekskludere ManagementWebSecurityAutoConfiguration.

3.1. Deaktivering kontra overgå sikkerhetsautokonfigurasjon

Det er en betydelig forskjell mellom å deaktivere autokonfigurasjon og å overgå den.

Ved å deaktivere det, er det akkurat som å legge til vårsikkerhetsavhengighet og hele oppsettet fra bunnen av. Dette kan være nyttig i flere tilfeller:

  1. Integrering av applikasjonssikkerhet med en tilpasset sikkerhetsleverandør
  2. Overføre en eldre vårapplikasjon med allerede eksisterende sikkerhetsoppsett - til Spring Boot

Men mesteparten av tiden trenger vi ikke å deaktivere sikkerhetsautokonfigurasjonen.

Måten Spring Boot er konfigurert på, tillater å overgå den autokonfigurerte sikkerheten ved å legge til i våre nye / egendefinerte konfigurasjonsklasser. Dette er vanligvis enklere, ettersom vi bare tilpasser et eksisterende sikkerhetsoppsett for å oppfylle våre behov.

4. Konfigurere sikkerhet for fjærstart

Hvis vi har valgt banen for å deaktivere automatisk konfigurasjon av sikkerhet, må vi naturlig gi vår egen konfigurasjon.

Som vi har diskutert tidligere, er dette standard sikkerhetskonfigurasjon; vi kan tilpasse det ved å endre eiendomsfilen.

Vi kan for eksempel overstyre standardpassordet ved å legge til vårt eget:

spring.security.user.password = passord

Hvis vi ønsker en mer fleksibel konfigurasjon, med for eksempel flere brukere og roller - må vi gjøre bruk av en fullstendig @Konfigurasjon klasse:

@Configuration @EnableWebSecurity offentlig klasse BasicConfiguration utvider WebSecurityConfigurerAdapter {@Override-beskyttet tomkonfigurasjon (AuthenticationManagerBuilder auth) kaster Unntak {PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder (); auth .inMemoryAuthentication () .withUser ("user") .password (encoder.encode ("password")) .roles ("USER"). and () .withUser ("admin") .password (encoder.encode (" admin ")) .roles (" BRUKER "," ADMIN "); } @ Override-beskyttet tomkonfigurasjon (HttpSecurity http) kaster Unntak {http .authorizeRequests () .anyRequest () .authenticated () .and () .httpBasic (); }}

De @EnableWebSecurity merknader er avgjørende hvis vi deaktiverer standard sikkerhetskonfigurasjon.

Hvis det mangler, starter ikke applikasjonen. Merknaden er bare valgfri hvis vi bare overstyrer standardoppførselen ved hjelp av a WebSecurityConfigurerAdapter.

Legg også merke til at vi trenger å bruke PasswordEncoder for å angi passordene når du bruker Spring Boot 2. For mer informasjon, se vår guide om standard passordkoder i Spring Security 5.

Nå bør vi bekrefte at sikkerhetskonfigurasjonen gjelder riktig med et par raske live-tester:

@RunWith (SpringRunner.class) @SpringBootTest (webEnvironment = RANDOM_PORT) offentlig klasse BasicConfigurationIntegrationTest {TestRestTemplate restTemplate; URL-base; @LocalServerPort int-port; @Før offentlig ugyldig setUp () kaster MalformedURLException {restTemplate = ny TestRestTemplate ("bruker", "passord"); base = ny URL ("// localhost:" + port); } @Test offentlig ugyldig nårLoggedUserRequestsHomePage_ThenSuccess () kaster IllegalStateException, IOException {ResponseEntity response = restTemplate.getForEntity (base.toString (), String.class); assertEquals (HttpStatus.OK, response.getStatusCode ()); assertTrue (respons.getBody (). inneholder ("Baeldung")); } @Test offentlig ugyldig nårUserWithWrongCredentials_thenUnauthorizedPage () kaster unntak {restTemplate = ny TestRestTemplate ("bruker", "feilpassord"); ResponseEntity respons = restTemplate.getForEntity (base.toString (), String.class); assertEquals (HttpStatus.UNAUTHORIZED, response.getStatusCode ()); assertTrue (respons.getBody (). inneholder ("Uautorisert")); }}

Tanken er at bak Spring Boot Security er faktisk Spring Security, så enhver sikkerhetskonfigurasjon som kan gjøres med denne, eller hvilken som helst integrasjon denne støtter, kan også implementeres i Spring Boot.

5. Spring Boot OAuth2 Auto-Configuration (bruker eldre stabel)

Spring Boot har en dedikert autokonfigurasjonsstøtte for OAuth2.

Spring Security OAuth-støtte som fulgte med Spring Boot 1.x ble fjernet i senere oppstartsversjoner i stedet for førsteklasses OAuth-støtte som følger med Spring Security 5. Vi ser hvordan du bruker det i neste avsnitt.

For den eldre stakken (ved bruk av Spring Security OAuth), må vi først legge til en Maven-avhengighet for å begynne å konfigurere applikasjonen vår:

 org.springframework.security.oauth spring-security-oauth2 

Denne avhengigheten inkluderer et sett med klasser som er i stand til å utløse den automatiske konfigurasjonsmekanismen som er definert i OAuth2AutoConfiguration klasse.

Nå har vi flere valg å fortsette, avhengig av omfanget av applikasjonen vår.

5.1. OAuth2 autorisasjonsserver automatisk konfigurasjon

Hvis vi vil at søknaden vår skal være en OAuth2-leverandør, kan vi bruke den @EnableAuthorizationServer.

Ved oppstart vil vi legge merke til i loggene at autokonfigurasjonsklassene vil generere en klient-ID og en klienthemmelighet for autorisasjonsserveren vår og selvfølgelig et tilfeldig passord for grunnleggende autentisering.

Bruker standard sikkerhetspassord: a81cb256-f243-40c0-a585-81ce1b952a98 security.oauth2.client.client-id = 39d2835b-1f87-4a77-9798-e2975f36972e security.oauth2.client.client-secret = f1463f8b-0791-46fe -521b86c55b71

Disse legitimasjonene kan brukes til å skaffe et tilgangstoken:

krølle -X POST -u 39d2835b-1f87-4a77-9798-e2975f36972e: f1463f8b-0791-46fe-9269-521b86c55b71 \ -d grant_type = client_credentials -d brukernavn = bruker -d passord = a81cb256-f243-40a01 -d omfang = skriv // localhost: 8080 / oauth / token

Vår annen artikkel gir ytterligere detaljer om emnet.

5.2. Andre Spring Boot OAuth2 Auto-Configuration Settings

Det er noen andre brukssaker som dekkes av Spring Boot OAuth2 som:

  1. Ressursserver - @EnableResourceServer
  2. Kundesøknad - @ EnableOAuth2Sso eller @ AktiverOAuth2Client

Hvis vi trenger at applikasjonen vår er en av typene ovenfor, må vi bare legge til noen konfigurasjoner i applikasjonsegenskapene, som beskrevet av lenkene det er referert til ovenfor.

Alle OAuth2-spesifikke egenskaper finnes på Spring Boot Common Application Properties.

6. Spring Boot OAuth2 Auto-Configuration (bruker ny stabel)

For å bruke den nye stakken, må vi legge til avhengigheter basert på det vi vil konfigurere - en autorisasjonsserver, en ressursserver eller et klientprogram.

La oss se på dem en etter en.

6.1. Støtte for OAuth2 autorisasjonsserver

Som vi så i forrige del, ga Spring Security OAuth-stakken muligheten for å sette opp en autorisasjonsserver som en vårapplikasjon. Men prosjektet er avviklet, og Spring støtter ikke sin egen autorisasjonsserver per nå. I stedet anbefales det å bruke eksisterende veletablerte leverandører som Okta, Keycloak og Forgerock.

Imidlertid gjør Spring Boot det enkelt for oss å konfigurere slike leverandører. For et eksempel på Keycloak-konfigurasjon, kan vi referere til enten En hurtigveiledning for bruk av Keycloak med Spring Boot eller Keycloak Embedded in a Spring Boot Application.

6.2. Støtte for OAuth2 ressursserver

For å inkludere støtte for en ressursserver, må vi legge til denne avhengigheten:

 org.springframework.boot spring-boot-starter-oauth2-resource-server 

For den siste versjonen, gå til Maven Central.

I tillegg må vi inkludere. I sikkerhetskonfigurasjonen oauth2ResourceServer () DSL:

@Configuration offentlig klasse JWTSecurityConfig utvider WebSecurityConfigurerAdapter {@Override-beskyttet tomkonfigurasjon (HttpSecurity http) kaster unntak {http ... .oauth2ResourceServer (oauth2 -> oauth2.jwt ()); ...}}

Vår OAuth 2.0 ressursserver med Spring Security 5 gir en grundig oversikt over dette emnet.

6.3. OAuth2 klientstøtte

I likhet med hvordan vi konfigurerte en ressursserver, trenger et klientprogram også sine egne avhengigheter og DSL-er.

Her er den spesifikke avhengigheten for OAuth2-klientstøtte:

 org.springframework.boot spring-boot-starter-oauth2-client 

Den siste versjonen finner du på Maven Central.

Spring Security 5 gir også førsteklasses påloggingsstøtte via sin oath2Login () DSL.

For detaljer om SSO-støtte i den nye stakken, se vår enkle enkel pålogging med Spring Security OAuth2.

7. Spring Boot 2 Security vs Spring Boot 1 Security

Sammenlignet med Spring Boot 1, Spring Boot 2 har i stor grad forenklet den automatiske konfigurasjonen.

I Spring Boot 2, hvis vi ønsker vår egen sikkerhetskonfigurasjon, kan vi ganske enkelt legge til en egendefinert WebSecurityConfigurerAdapter. Dette vil deaktivere standard auto-konfigurasjon og aktivere vår tilpassede sikkerhetskonfigurasjon.

Spring Boot 2 bruker de fleste av Spring Securitys standardinnstillinger. På grunn av dette, noen av sluttpunktene som ikke var sikret som standard i Spring Boot 1 er nå sikret som standard.

Disse endepunktene inkluderer statiske ressurser som / css / **, / js / **, / images / **, / webjars / **, /**/favicon.ico, og feilendepunktet. Hvis vi trenger å tillate uautentisert tilgang til disse endepunktene, kan vi eksplisitt konfigurere det.

For å forenkle den sikkerhetsrelaterte konfigurasjonen, Spring Boot 2 har fjernet følgende Spring Boot 1-egenskaper:

security.basic.authorize-mode security.basic.enabled security.basic.path security.basic.realm security.enable-csrf security.headers.cache security.headers.content-security-policy security.headers.content-security-policy -modus security.headers.content-type security.headers.frame security.headers.hsts security.headers.xss security.ignored security.require-ssl security.sessions

8. Konklusjon

I denne artikkelen fokuserte vi på standard sikkerhetskonfigurasjon gitt av Spring Boot. Vi så hvordan den automatiske sikkerhetskonfigurasjonsmekanismen kan deaktiveres eller overstyres, og hvordan en ny sikkerhetskonfigurasjon kan brukes.

Kildekoden for OAuth2 finner du på OAuth2 GitHub-depotet vårt, for eldre og ny stack. Resten av koden finner du på tutorials GitHub.


$config[zx-auto] not found$config[zx-overlay] not found