streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban a tavaszi biztonsági kifejezésekre összpontosítunk, és természetesen a kifejezések gyakorlati példáira.

A bonyolultabb megvalósítások (például az ACL) áttekintése előtt fontos, hogy alaposan átfogja a biztonsági kifejezéseket - mivel megfelelő használat esetén meglehetősen rugalmasak és hatékonyak lehetnek.

Ez a cikk a Spring Security Expressions - hasRole Example kiterjesztése.

2. Maven-függőségek

A Spring Security használatához be kell illesztenie a következő szakaszt a pom.xml fájl:

  org.springframework.security spring-security-web 5.2.3.KÖZLEMÉNY 

A legfrissebb verzió itt található.

És egy rövid megjegyzés: ez a függőség csak a Spring Securityre terjed ki; ne felejts el hozzáadni s-tpring-core és tavaszi kontextus egy teljes webes alkalmazáshoz.

3. Konfiguráció

Először vessünk egy pillantást egy Java konfigurációra.

Meghosszabbítjuk WebSecurityConfigurerAdapter - hogy lehetőségünk legyen az alaposztály bármelyik kiterjesztési pontjára bekapcsolni:

@Configuration @EnableAutoConfiguration @EnableWebSecurity @EnableGlobalMethodSecurity (prePostEnabled = true) nyilvános osztály A SecurityJavaConfig kiterjeszti a WebSecurityConfigurerAdapter {...}

Természetesen elvégezhetünk egy XML konfigurációt is:

4. Webbiztonsági kifejezések

Most kezdjük el megvizsgálni a biztonsági kifejezéseket:

• hasRole, hasAnyRole
• hasAuthority, hasAnyAuthority
• allowAll, denyAll
• isAnonymous, isRememberMe, isHitelesítve, isFullyAuthentified
• fő, hitelesítés
• hasPermission

És most nézzük át ezeket részletesen.

4.1. hasRole, hasAnyRole

Ezek a kifejezések felelősek az alkalmazás URL-jeinek vagy módszereinek hozzáférés-felügyeletének vagy engedélyezésének meghatározásáért.

Nézzük meg a példát:

A @Orride védett void konfiguráció (végső HttpSecurity http) a Kivételt dobja ... {antantMatchers ("/ auth / admin / *"). HasRole ("ADMIN") .antMatchers ("/ auth / *"). "," USER ") ...} 

Ebben a példában megadjuk a hozzáférést az összes kezdő linkhez / auth / azokra a felhasználókra korlátozódik, akik szerepkörrel vannak bejelentkezve FELHASZNÁLÓ vagy szerep ADMIN. Sőt, a kezdő linkek eléréséhez / auth / admin / nekünk kell ADMIN szerepe a rendszerben.

Ugyanez a konfiguráció elérhető az XML fájlban, a következő írásával:

4.2. hasAuthority, hasAnyAuthority

A szerepek és a hatóságok hasonlóak tavasszal.

A fő különbség az, hogy a szerepeknek különleges szemantikájuk van - kezdve a Spring Security 4-től, aSZEREP_‘Az előtagot automatikusan hozzáadja (ha még nincs ott) bármely szerepkörrel kapcsolatos módszer.

Így hasAuthority (‘ROLE_ADMIN’) hasonló hasRole (’ADMIN’) mert a 'SZEREP_‘Az előtag automatikusan hozzáadódik.

De az a jó a hatóságok használatában, hogy nem kell használnunk a SZEREP_ előtag egyáltalán.

Itt egy rövid példa, ahol meghatározzuk a felhasználókat meghatározott jogosultságokkal:

A @Orride védett érvénytelen konfiguráció (AuthenticationManagerBuilder withUser ("admin"). jelszó (encoder (). encode ("adminPass")) .authorities ("ADMIN"); } 

Ezután természetesen használhatjuk ezeket a hatósági kifejezéseket:

A @Orride védett void konfiguráció (végső HttpSecurity http) dobja a kivételt {... .antMatchers ("/ auth / admin / *"). HasAuthority ("ADMIN") .antMatchers ("/ auth / *"). HasAnyAuthority ("ADMIN "," USER ") ...}

Mint láthatjuk - itt egyáltalán nem említünk szerepeket. Emellett az 5. tavasztól szükségünk van a PasswordEncoder bab:

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

Végül - természetesen ugyanazt a funkciót is elérhetjük az XML konfigurációval:

És:

4.3. allowAll, denyAll

Ez a két kommentár is elég egyértelmű. Vagy engedélyezhetjük a szolgáltatásunk URL-jéhez való hozzáférést, vagy megtagadhatjuk a hozzáférést.

Vessünk egy pillantást a példára:

... .antMatchers ("/ *"). allowAll () ...

Ezzel a konfigurációval minden felhasználót (mind névtelen, mind bejelentkezett felhasználót) felhatalmazunk a '/' betűvel kezdődő oldal (például a kezdőlapunk) elérésére.

Megtagadhatjuk a teljes URL-területünkhöz való hozzáférést is:

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

Ismét ugyanaz a konfiguráció elvégezhető egy XML konfigurációval is:

4.4. isAnonymous, isRememberMe, isAuthenticated, isFullyAuthenticated

Ebben az alfejezetben a felhasználó bejelentkezési állapotához kapcsolódó kifejezésekre összpontosítunk. Kezdjük azzal a felhasználóval, aki nem jelentkezett be az oldalunkra. Az alábbiak megadásával a Java config-ban minden jogosulatlan felhasználó számára lehetővé tesszük a főoldalunk elérését:

... .antMatchers ("/ *"). névtelen () ...

Ugyanez az XML konfigurációban:

Ha meg akarjuk védeni azt a weboldalt, amelybe mindenkinek be kell jelentkeznie, aki használja, akkor azt be kell használnunk isAuthentified () módszer:

... .antMatchers ("/ *"). hitelesítve () ...

vagy XML verzió:

Sőt, van két további kifejezésünk, isRememberMe () és isFullyAuthenticated (). A sütik használatával a Spring lehetővé teszi az emlékszem képességeit, így nem kell minden alkalommal bejelentkezni a rendszerbe. Tudjon meg többet erről Emlékezz rám itt.

Annak érdekében, hogy hozzáférést biztosítsunk azoknak a felhasználóknak, akiket csak az Emlékezzen rám funkció lépett be, használhatjuk ezt:

... .antMatchers ("/ *"). RememberMe () ...

vagy XML verzió:

Végül, szolgáltatásaink bizonyos részei megkövetelik a felhasználó újbóli hitelesítését, még akkor is, ha a felhasználó már be van jelentkezve. Például a felhasználó módosítani szeretné a beállításokat vagy a fizetési információkat; természetesen jó gyakorlat kézi hitelesítést kérni a rendszer érzékenyebb területein.

Ennek érdekében meghatározhatjuk isFullyAuthenticated (), amely visszatér igaz ha a felhasználó nem névtelen vagy emlékszik rám:

... .antMatchers ("/ *"). teljesen hitelesítve () ...

vagy az XML verzió:

4.5. megbízó, hitelesítés

Ezek a kifejezések lehetővé teszik a fő az aktuálisan engedélyezett (vagy névtelen) felhasználót és az aktuális felhasználót képviselő objektum Hitelesítés objektum a SecurityContextill.

Használhatjuk például fő a felhasználó e-mailjének, avatárjának vagy bármely más adatnak a betöltéséhez, amely elérhető a bejelentkezett felhasználóban.

És hitelesítés információt nyújt a teljes Hitelesítés objektumot, annak meghatalmazottjaival együtt.

Mindkettőt részletesebben ismerteti a következő cikk: Felhasználói információk letöltése a Spring Security alkalmazásban.

4.6. hasPermission API-k

Ezt a kifejezést dokumentálják, és célja az, hogy áthidalja az expressziós rendszert és a Spring Security ACL rendszerét, lehetővé téve számunkra, hogy absztrakt engedélyek alapján meghatározzuk az egyes tartományi objektumok engedélyezési korlátozásait.

Nézzünk meg egy példát. Van egy szolgáltatásunk, amely lehetővé teszi a kooperatív cikkek írását, főszerkesztővel, eldöntve, hogy a többi szerző által javasolt cikket melyiknek kellene közzétenni.

Az ilyen szolgáltatás használatának engedélyezése érdekében a következő módszereket hozhatjuk létre hozzáférés-vezérlési módszerekkel:

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

Csak a jogosult felhasználó hívhatja meg ezt a módszert, és a felhasználónak is engedélyre van szüksége isEditor a szolgálatban.

Arra is emlékeznünk kell, hogy kifejezetten konfiguráljuk a PermissionEvaluator pályázati környezetünkben:

hol customInterfaceImplementation osztály lesz, amely megvalósítja PermissionEvaluator.

Természetesen ezt Java konfigurációval is megtehetjük:

@Orride protected MethodSecurityExpressionHandler expressionHandler () {DefaultMethodSecurityExpressionHandler expressionHandler = new DefaultMethodSecurityExpressionHandler (); kifejezésHandler.setPermissionEvaluator (új CustomInterfaceImplementation ()); return kifejezésHandler; }

5. Következtetés

Ez az oktatóanyag a Spring Security Expressions átfogó bemutatása és útmutatója.

Az itt tárgyalt összes példa elérhető a GitHub projektről.