streamalism.org

1. Introduksjon

I denne opplæringen vil vi fokusere på Spring Security Expressions, og selvfølgelig på praktiske eksempler med disse uttrykkene.

Før du ser på mer komplekse implementeringer (for eksempel ACL), er det viktig å ha et solid grep om sikkerhetsuttrykk - da de kan være ganske fleksible og kraftige hvis de brukes riktig.

Denne artikkelen er en utvidelse av Spring Security Expressions - hasRole Eksempel.

2. Maven-avhengigheter

For å kunne bruke Spring Security, må du inkludere følgende avsnitt i din pom.xml fil:

  org.springframework.security spring-security-web 5.2.3.RELEASE 

Siste versjon finner du her.

Og et raskt notat - denne avhengigheten dekker bare vårsikkerhet; ikke glem å legge til spring-core og vår-kontekst for en fullstendig webapplikasjon.

3. Konfigurasjon

La oss først se på en Java-konfigurasjon.

Vi vil utvide WebSecurityConfigurerAdapter - slik at vi har muligheten til å koble til noen av utvidelsespunktene som baseklassen tilbyr:

@Configuration @EnableAutoConfiguration @EnableWebSecurity @EnableGlobalMethodSecurity (prePostEnabled = true) offentlig klasse SecurityJavaConfig utvider WebSecurityConfigurerAdapter {...}

Vi kan selvfølgelig også gjøre en XML-konfigurasjon:

4. Websikkerhetsuttrykk

La oss nå se på sikkerhetsuttrykkene:

• hasRole, hasAnyRole
• harAuthority, harAnyAuthority
• tillatelseAlle, fornekte alt
• er anonym, erHusk meg, er godkjent, er fullstendig godkjent
• rektor, godkjenning
• hasPermission

Og la oss nå gå gjennom hver av disse i detalj.

4.1. hasRole, hasAnyRole

Disse uttrykkene er ansvarlige for å definere tilgangskontroll eller autorisasjon til spesifikke nettadresser eller metoder i applikasjonen din.

La oss se på eksemplet:

@ Override beskyttet ugyldig konfigurasjon (endelig HttpSecurity http) kaster unntak {... .antMatchers ("/ auth / admin / *"). HasRole ("ADMIN") .antMatchers ("/ auth / *"). HasAnyRole ("ADMIN "," USER ") ...} 

I dette eksemplet spesifiserer vi tilgang til alle lenker som begynner med / auth / begrenset til brukere som er logget på med rolle BRUKER eller rolle ADMIN. Videre for å få tilgang til lenker som begynner med / autent / admin / vi trenger å ha ADMIN rolle i systemet.

Den samme konfigurasjonen kan oppnås i XML-fil ved å skrive:

4.2. hasAuthority, hasAnyAuthority

Roller og myndigheter er like våren.

Hovedforskjellen er at roller har spesiell semantikk - med utgangspunkt i Spring Security 4,ROLE_‘Prefikset blir automatisk lagt til (hvis det ikke allerede er der) med en hvilken som helst rollerelatert metode.

Så hasAuthority (‘ROLE_ADMIN’) den er lik hasRole (‘ADMIN’) fordi det 'ROLE_‘Prefikset blir lagt til automatisk.

Men det som er bra med å bruke myndigheter, er at vi ikke trenger å bruke ROLE_ prefiks i det hele tatt.

Her er et raskt eksempel der vi definerer brukere med bestemte myndigheter:

@ Override-beskyttet tomkonfigurasjon (AuthenticationManagerBuilder auth) kaster unntak {auth.inMemoryAuthentication () .withUser ("user1"). Passord (encoder (). Encode ("user1Pass")) .authorities ("USER") og (). withUser ("admin"). passord (encoder (). encode ("adminPass")). autoriteter ("ADMIN"); } 

Vi kan da selvfølgelig bruke disse myndighetens uttrykk:

@ Override-beskyttet tomkonfigurasjon (endelig HttpSecurity http) kaster unntak {... .antMatchers ("/ auth / admin / *"). HasAuthority ("ADMIN") .antMatchers ("/ auth / *"). HasAnyAuthority ("ADMIN "," USER ") ...}

Som vi kan se - nevner vi ikke roller i det hele tatt her. I tillegg, fra og med våren 5, trenger vi en PasswordEncoder bønne:

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

Til slutt - vi kan selvfølgelig oppnå den samme funksjonaliteten ved å bruke XML-konfigurasjon også:

Og:

4.3. permitAll, denyAll

Disse to kommentarene er også ganske greie. Vi kan enten tillate tilgang til noen nettadresser i tjenesten vår, eller vi kan nekte tilgang.

La oss ta en titt på eksemplet:

... .antMatchers ("/ *"). permitAll () ...

Med denne konfigurasjonen vil vi autorisere alle brukere (både anonyme og påloggede) til å få tilgang til siden fra og med ‘/ '(for eksempel hjemmesiden vår).

Vi kan også nekte tilgang til hele vår URL-plass:

... .antMatchers ("/ *"). denyAll () ...

Og igjen, den samme konfigurasjonen kan også gjøres med en XML-konfigurasjon:

4.4. isAnonymous, isRememberMe, isAuthenticated, isFlylyAuthenticated

I dette underavsnittet fokuserer vi på uttrykk relatert til brukerens påloggingsstatus. La oss starte med bruker som ikke logget inn på siden vår. Ved å spesifisere følgende i Java config, lar vi alle uautoriserte brukere få tilgang til hovedsiden vår:

... .antMatchers ("/ *"). anonym () ...

Det samme i XML config:

Hvis vi ønsker å sikre nettstedet at alle som bruker det, blir pålagt å logge inn, må vi bruke det isAuthenticated () metode:

... .antMatchers ("/ *"). autentisert () ...

eller XML-versjon:

Videre har vi to ytterligere uttrykk, isRememberMe () og isFullyAuthenticated (). Gjennom bruk av informasjonskapsler muliggjør Spring husk meg, så det er ikke nødvendig å logge inn på systemet hver gang. Du kan lese mer om Husk meg her.

For å gi tilgang til brukere som bare var logget inn av remember me-funksjonen, kan vi bruke dette:

... .antMatchers ("/ *"). rememberMe () ...

eller XML-versjon:

Til slutt krever noen deler av tjenestene at brukeren godkjennes igjen selv om brukeren allerede er logget inn. For eksempel vil brukeren endre innstillinger eller betalingsinformasjon; det er selvfølgelig god praksis å be om manuell autentisering i de mer følsomme områdene av systemet.

For å gjøre det kan vi spesifisere isFullyAuthenticated (), som kommer tilbake ekte hvis brukeren ikke er anonym eller husker meg:

... .antMatchers ("/ *"). fullyAuthenticated () ...

eller XML-versjonen:

4.5. rektor, autentisering

Disse uttrykkene gir tilgang til rektor objekt som representerer den nåværende autoriserte (eller anonyme) brukeren og den nåværende Godkjenning objekt fra SecurityContext, henholdsvis.

Vi kan for eksempel bruke rektor for å laste inn en brukers e-post, avatar eller andre data som er tilgjengelige i den påloggede brukeren.

Og godkjenning gir informasjon om det fulle Godkjenning innvending, sammen med de tildelte myndighetene.

Begge er beskrevet nærmere i følgende artikkel: Hent brukerinformasjon i Spring Security.

4.6. hasPermission APIer

Dette uttrykket er dokumentert og ment for å bygge bro mellom uttrykkssystemet og Spring Securitys ACL-system, slik at vi kan spesifisere autorisasjonsbegrensninger for individuelle domeneobjekter, basert på abstrakte tillatelser.

La oss se på et eksempel. Vi har en tjeneste som tillater samarbeidende skriveartikler, med en hovedredaktør som bestemmer hvilken artikkel foreslått av andre forfattere skal publiseres.

For å tillate bruk av en slik tjeneste, kan vi opprette følgende metoder med tilgangskontrollmetoder:

@PreAuthorize ("hasPermission (#articleId, 'isEditor')") public void acceptArticle (Article Article) {...}

Bare autoriserte brukere kan ringe til denne metoden, og brukeren må også ha tillatelse isEditor i tjenesten.

Vi må også huske å konfigurere en eksplisitt PermissionEvaluator i vår søknadssammenheng:

hvor customInterfaceImplementation vil være klassen som implementerer PermissionEvaluator.

Selvfølgelig kan vi også gjøre dette med Java-konfigurasjon:

@ Override-beskyttet MethodSecurityExpressionHandler expressionHandler () {DefaultMethodSecurityExpressionHandler expressionHandler = ny DefaultMethodSecurityExpressionHandler (); expressionHandler.setPermissionEvaluator (ny CustomInterfaceImplementation ()); return expressionHandler; }

5. Konklusjon

Denne opplæringen er en omfattende introduksjon og guide til Spring Security Expressions.

Alle eksemplene som er diskutert her, er tilgjengelige på GitHub-prosjektet.