streamalism.org

1. Oversigt

I denne vejledning skal vi tale om @EnableResourceServer og @ EnableOAuth2Sso kommentarer i Spring Security.

Vi begynder med at forklare forskelle mellem en OAuth2 Klient og en OAuth2 Ressource server. Bagefter vil vi tale lidt om, hvad disse kommentarer kan gøre for os og demonstrere deres brug med et eksempel ved hjælp af Zuul og en simpel API.

Med henblik på denne artikel vil vi antage nogle allerede eksisterende erfaringer med Zuul og OAuth2.

Hvis du ikke har nogen eller føler, at en gennemgang af en af ​​dem vil være nyttigt, henvises til vores hurtige oversigt over Zuul og vores guide til OAuth2.

2. OAuth2-klient og ressource-server

Der er fire forskellige roller inden for OAuth2 skal vi overveje:

• Ressourceejer - en enhed, der er i stand til at give adgang til sine beskyttede ressourcer
• Autorisationsserver - giver adgangsbrikker til Kunder efter godkendelse RessourceEjere og få deres tilladelse
• Ressource server - en komponent, der kræver et adgangstoken for at tillade eller i det mindste overveje adgang til dets ressourcer
• Klient - en enhed, der er i stand til at få adgangstokener fra autorisationsservere

Annotering af vores konfigurationsklasse med @EnableResourceServer, eller @ EnableOAuth2Sso, instruerer Spring til at konfigurere komponenter, der omdanner vores applikation til en af ​​de to sidstnævnte roller nævnt ovenfor.

Det @EnableResourceServer annotering gør det muligt for vores applikation at opføre sig som en Ressource server ved at konfigurere en OAuth2AuthenticationProcessingFilter og andre lige så vigtige komponenter.

Tjek ResourceServerSecurityConfigurer klasse for at få en bedre idé om, hvad der konfigureres bag kulisserne.

Omvendt det @ EnableOAuth2Sso annotation omdanner vores applikation til en OAuth2-klient. Det instruerer foråret at konfigurere en OAuth2ClientAuthenticationProcessingFiltersammen med andre komponenter, som vores applikation skal kunne få adgangstokener fra en autorisationsserver.

Se på SsoSecurityConfigurer klasse for yderligere detaljer om, hvad Spring konfigurerer for os.

Ved at kombinere disse kommentarer med nogle egenskaber kan vi hurtigt få tingene i gang. Lad os oprette to forskellige applikationer for at se dem i aktion, og hvordan de kan supplere hinanden:

• Vores første applikation bliver vores edge node, en simpel Zuul applikation, der skal bruges @ EnableOAuth2Sso kommentar. Det vil være ansvarligt for godkendelse af brugere (ved hjælp af en BemyndigelseServer) og delegere indgående anmodninger til andre applikationer
• Den anden applikation skal bruges @EnableResourceServer kommentar og giver adgang til beskyttede ressourcer, hvis de indgående anmodninger indeholder et gyldigt OAuth2-adgangstoken

3. Zuul - @ EnableOAuth2Sso

Lad os starte med at oprette en Zuul applikation, der skal fungere som vores kantnode og vil være ansvarlig for godkendelse af brugere ved hjælp af en OAuth2 BemyndigelseServer:

@Configuration @EnableZuulProxy @ EnableOAuth2Sso @ Order (værdi = 0) offentlig klasse AppConfiguration udvider WebSecurityConfigurerAdapter {@Autowired private ResourceServerTokenServices resourceServerTokenServices; @ Override offentlig ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.csrf (). Deaktiver () .authorizeRequests () .antMatchers ("/ autorisationsserver-1 / **", "/ login"). PermitAll (). anyRequest (). godkendt (). og () .logout (). permitAll (). logoutSuccessUrl ("/"); }}

Annoterer vores Zuul ansøgning med @ EnableOAuth2Sso giver også Spring besked om at konfigurere en OAuth2TokenRelayFilter filter. Dette filter henter tidligere opnåede adgangstokener fra brugernes HTTP-sessioner og udbreder dem nedstrøms.

Bemærk, at vi også bruger @Bestille kommentar i vores Appkonfiguration konfigurationsklasse. Dette er for at sikre, at Filtre skabt af vores WebSecurityConfigurerAdapter have forrang over Filtre skabt af andre WebSecurityConfigurerAdapters.

For eksempel kunne vi kommentere vores Zuul ansøgning med @EnableResourceServer til at understøtte både HTTP-sessionsidentifikatorer og OAuth2-adgangstokener. Imidlertid skaber det nyt Filtre at som standard har forrang over dem, der er oprettet af Appkonfiguration klasse. Dette sker fordi ResouceServerConfiguration, en konfigurationsklasse udløst af @EnableResourceServer, angiver en standard bestille af 3 mens WebSecurityConfigureAdapter har en standardindstilling bestille på 100.

Før vi går videre til vores RessourceServer, vi er nødt til at konfigurere nogle egenskaber:

zuul: ruter: resource-server-mvc-1: / resource-server-mvc-1 / ** autorisationsserver-1: sensitiveHeaders: Autorisationssti: / autorisationsserver-1 / ** stripPrefix: falsk tilføjelsesproxy- overskrifter: sand sikkerhed: grundlæggende: aktiveret: falsk oauth2: sso: loginPath: / login klient: accessTokenUri: // localhost: 8769 / autorisationsserver-1 / oauth / token brugerAuthorizationUri: / autorisationsserver-1 / oauth / autoriser clientId : fooClient clientSecret: fooSecret ressource: jwt: keyValue: "abc" id: fooScope serviceId: $ {PREFIX:} resource

Uden at gå for meget i detaljer ved hjælp af denne konfiguration er vi:

• Konfiguration af vores Zuul ruter og siger, hvilke overskrifter der skal tilføjes / fjernes, inden der sendes anmodninger nedstrøms.
• Indstilling af nogle OAuth2-egenskaber, så vores applikation kan kommunikere med vores BemyndigelseServer og konfiguration JWT med symmetrisk kryptering.

4. API - @EnableResourceServer

Nu hvor vi har vores Zuul applikation på plads, lad os oprette vores RessourceServer:

@SpringBootApplication @EnableResourceServer @Controller @RequestMapping ("/") klasse ResourceServerApplication {offentlig statisk ugyldig main (String [] args) {SpringApplication.run (ResourceServerApplication.class, args); } @RequestMapping (method = RequestMethod.GET) @ResponseBody public String helloWorld (Principal principal) {return "Hello" + principal.getName (); }}

Det er en simpel applikation, der udsætter et enkelt slutpunkt for at returnere navn af Rektor der startede anmodningen.

Lad os afslutte ved at konfigurere nogle egenskaber:

sikkerhed: grundlæggende: aktiveret: falsk oauth2: ressource: jwt: keyValue: "abc" id: fooScope service-id: $ {PREFIX:} ressource

Husk det vi har brug for et gyldigt adgangstoken (som er gemt i HTTP-sessionen for brugeren i vores kantnode) for at få adgang til slutpunktet for vores RessourceServer.

5. Konklusion

I denne artikel forklarede vi forskellene mellem @ EnableOAuth2Sso og @EnableResourceServer kommentarer. Vi demonstrerede også, hvordan man bruger dem med et praktisk eksempel ved hjælp af Zuul og en simpel API.

Den fulde implementering af dette eksempel kan findes på Github.

Når vi kører lokalt, kan vi køre og teste applikationen på //192.168.1.67:8765/resource-server-mvc-1