streamalism.org

1. Introduktion

I denne vejledning fokuserer vi på Spring Security Expressions og naturligvis på praktiske eksempler med disse udtryk.

Før du ser på mere komplekse implementeringer (såsom ACL), er det vigtigt at have et solidt greb om sikkerhedsudtryk - da de kan være ret fleksible og kraftfulde, hvis de bruges korrekt.

Denne artikel er en udvidelse af Spring Security Expressions - hasRole Eksempel.

2. Maven-afhængigheder

For at kunne bruge Spring Security skal du medtage følgende afsnit i din pom.xml fil:

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

Seneste version kan findes her.

Og en hurtig bemærkning - denne afhængighed dækker kun Spring Security; glem ikke at tilføje spring-core og forårskontekst for en komplet webapplikation.

3. Konfiguration

Lad os først se på en Java-konfiguration.

Vi strækker os ud WebSecurityConfigurerAdapter - så vi har mulighed for at tilslutte et af de udvidelsespunkter, som baseklassen tilbyder:

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

Vi kan selvfølgelig også lave en XML-konfiguration:

4. Websikkerhedsudtryk

Lad os nu se på sikkerhedsudtrykkene:

• hasRole, hasAnyRole
• har autoritet, hasAnyAuthority
• tilladelseAlle, benægte alt
• er anonym, erHuskMe, er godkendt, isFullyAuthenticated
• rektor, Godkendelse
• hasPermission

Og lad os nu gå igennem hver af disse i detaljer.

4.1. hasRole, hasAnyRole

Disse udtryk er ansvarlige for at definere adgangskontrol eller autorisation til specifikke URL'er eller metoder i din applikation.

Lad os se på eksemplet:

@ Override beskyttet ugyldig konfiguration (endelig HttpSecurity http) kaster undtagelse {... .antMatchers ("/ auth / admin / *"). HasRole ("ADMIN") .antMatchers ("/ auth / *"). HasAnyRole ("ADMIN "," BRUGER ") ...} 

I dette eksempel specificerer vi adgang til alle links startende med / autent / begrænset til brugere, der er logget ind med rolle BRUGER eller rolle ADMIN. Desuden for at få adgang til links, der starter med / autent / admin / vi skal have ADMIN rolle i systemet.

Den samme konfiguration kan opnås i XML-fil ved at skrive:

4.2. hasAuthority, hasAnyAuthority

Roller og myndigheder er ens i foråret.

Hovedforskellen er, at roller har speciel semantik - startende med Spring Security 4, 'ROL_'Præfikset tilføjes automatisk (hvis det ikke allerede er der) ved hjælp af en hvilken som helst rollerelateret metode.

Så hasAuthority (‘ROLE_ADMIN’) ligner hasRole ('ADMIN') fordi 'ROL_'Præfikset tilføjes automatisk.

Men det gode ved at bruge myndigheder er, at vi ikke behøver at bruge ROL_ præfiks overhovedet.

Her er et hurtigt eksempel, hvor vi definerer brugere med specifikke myndigheder:

@ Override beskyttet ugyldig konfiguration (AuthenticationManagerBuilder auth) kaster Undtagelse {auth.inMemoryAuthentication () .withUser ("user1"). Adgangskode (encoder (). Encode ("user1Pass")) .authorities ("USER") og (). withUser ("admin"). adgangskode (encoder (). encode ("adminPass")). autoriteter ("ADMIN"); } 

Vi kan så naturligvis bruge disse myndigheders udtryk:

@ Override beskyttet ugyldig konfiguration (endelig HttpSecurity http) kaster undtagelse {... .antMatchers ("/ auth / admin / *"). HarAuthority ("ADMIN") .antMatchers ("/ auth / *"). HasAnyAuthority ("ADMIN "," BRUGER ") ...}

Som vi kan se - nævner vi slet ikke roller her. Derudover skal vi starte en forår 5 PasswordEncoder bønne:

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

Endelig - vi kan naturligvis også opnå den samme funktionalitet ved hjælp af XML-konfiguration:

Og:

4.3. tilladelse til alle, benægt alt

Disse to kommentarer er også ret ligetil. Vi tillader enten adgang til en eller anden URL i vores tjeneste, eller vi nægter adgang.

Lad os se på eksemplet:

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

Med denne konfiguration godkender vi alle brugere (både anonyme og logget ind) til at få adgang til siden startende med ‘/ '(for eksempel vores hjemmeside).

Vi kan også nægte adgang til hele vores URL-plads:

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

Og igen kan den samme konfiguration også udføres med en XML-konfiguration:

4.4. isAnonymous, isRememberMe, isAuthenticated, isFullyAuthenticated

I dette underafsnit fokuserer vi på udtryk relateret til brugerens login-status. Lad os starte med en bruger, der ikke loggede ind på vores side. Ved at specificere følgende i Java config giver vi alle uautoriserede brugere adgang til vores hovedside:

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

Det samme i XML-konfiguration:

Hvis vi ønsker at sikre webstedet, at alle, der bruger det, skal logge ind, skal vi bruge det isAuthenticated () metode:

... .antMatchers ("/ *"). godkendt () ...

eller XML-version:

Desuden har vi to yderligere udtryk, isRememberMe () og isFullyAuthenticated (). Ved brug af cookies muliggør Spring husk mig-funktioner, så der er ikke behov for at logge ind på systemet hver gang. Du kan læse mere om Husk mig her.

For at give adgang til brugere, der kun var logget ind af funktionen husk mig, kan vi bruge denne:

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

eller XML-version:

Endelig kræver nogle dele af vores tjenester, at brugeren godkendes igen, selvom brugeren allerede er logget ind. F.eks. Ønsker brugeren at ændre indstillinger eller betalingsoplysninger; det er selvfølgelig god praksis at bede om manuel godkendelse i de mere følsomme områder af systemet.

For at gøre det kan vi specificere isFullyAuthenticated (), som vender tilbage rigtigt hvis brugeren ikke er anonym eller husker mig:

... .antMatchers ("/ *"). fuldt godkendt () ...

eller XML-versionen:

4.5. princip, godkendelse

Disse udtryk giver adgang til rektor objekt, der repræsenterer den aktuelle autoriserede (eller anonyme) bruger og den aktuelle Godkendelse objekt fra Sikkerhedskontekst, henholdsvis.

Vi kan for eksempel bruge rektor for at indlæse en brugers e-mail, avatar eller andre data, der er tilgængelige i den indloggede bruger.

Og Godkendelse giver information om det fulde Godkendelse gør indsigelse sammen med dets tildelte myndigheder.

Begge er beskrevet mere detaljeret i den følgende artikel: Hent brugeroplysninger i Spring Security.

4.6. hasPermission API'er

Dette udtryk er dokumenteret og beregnet til at bygge bro mellem ekspressionssystemet og Spring Securitys ACL-system, så vi kan specificere autorisationsbegrænsninger for individuelle domæneobjekter baseret på abstrakte tilladelser.

Lad os se på et eksempel. Vi har en tjeneste, der tillader kooperativt at skrive artikler med en hovedredaktør, der beslutter, hvilken artikel foreslået af andre forfattere skal offentliggøres.

For at tillade brug af en sådan tjeneste kan vi oprette følgende metoder med adgangskontrolmetoder:

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

Kun autoriseret bruger kan ringe til denne metode, og bruger skal også have tilladelse isEditor i tjenesten.

Vi skal også huske at udtrykkeligt konfigurere en PermissionEvaluator i vores applikationskontekst:

hvor customInterfaceImplementation vil være den klasse, der implementeres PermissionEvaluator.

Selvfølgelig kan vi også gøre dette med Java-konfiguration:

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

5. Konklusion

Denne vejledning er en omfattende introduktion og vejledning til Spring Security Expressions.

Alle eksempler, der diskuteres her, er tilgængelige på GitHub-projektet.