Microservicios y Spring Security OAuth2
spring-security oauth-2.0 (3)
Al configurar su servidor auh ::
Cree un nuevo ClientDetails en ClientDetailsServiceConfigurer
para el servidor de recursos. que se usará para configurar RemoteTokenService
.
Configure Spring Security OAuth2 en su servidor de recursos:
Cree una clase que sea anotada con @EnableWebSecurity
, @Configuration
y extienda WebSecurityConfigurerAdapter
.
@Configuration
@EnableWebSecurity
protected static class ResourceConfiguration extends WebSecurityConfigurerAdapter {
// methods
}
Cree un método con @Bean anotado que devolverá la instancia de TokenService
, que se usará para crear AuthenticationManager
.
En este método, cree una instancia de RemoteTokenService
y establezca clientId, client_secret, checkTokenEndpointUrl y DefaultAccessTokenConverterWithClientRoles
(esta clase es nuestra implementación para obtener client_authority mientras se autentica accessToken en el servidor OAuth2).
@Bean
public ResourceServerTokenServices tokenService() {
RemoteTokenServices tokenServices = new RemoteTokenServices();
tokenServices.setClientId("resource_id");
tokenServices.setClientSecret("resource_secret");
tokenServices.setCheckTokenEndpointUrl("http://<server-url>: <port>/oauth/check_token");
return tokenServices;
}
Reemplazar el método authenticationManagerBean()
y anotarlo con @Bean
y devolver una instancia de OAuth2AuthenticationManager
con TokenService
inyectado.
@Override
@Bean
public AuthenticationManager authenticationManagerBean() throws Exception {
OAuth2AuthenticationManager authenticationManager = new OAuth2AuthenticationManager();
authenticationManager.setTokenServices(tokenService());
return authenticationManager;
}
Cree una clase anotada con @EnableResourceServer
, @Configuration
y extienda ResourceServerConfigurerAdapter
.
@Configuration
@EnableResourceServer
protected static class ResourceServerConfig extends ResourceServerConfigurerAdapter {
// Mehotds
}
Anular Configurar métodos de la superclase para configurar el servidor de recursos. Configurable diferente para configurar el servidor de recursos.
ResourceServerSecurityConfigurer : para configurar Resource_id.
HttpSecurity : configurará el filtro de seguridad para indicarle que el usuario necesita autenticación para las URL protegidas (API).
@Override
public void configure(ResourceServerSecurityConfigurer resources) throws Exception {
resources.resourceId("resource_id");
}
@Override
public void configure(HttpSecurity http) throws Exception {
// @formatter:off
http
.authorizeRequests()
.antMatchers("/**").authenticated()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);
// @formatter:on
}
.antMatcher("/**").authenticated()
esta línea protegerá cada api url de su servidor de recursos. .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
no creará sesión.
PD: si algo está mal, entonces dígame.
Ya tengo un servidor de autorización OAuth2 ejecutándose en otro proyecto. Ahora necesitaría asegurar varios servidores de reposo con arranque de resorte simple con OAuth2. Pero estoy encontrando que la documentación de Spring realmente es muy limitada cuando se trata de separar los servidores de Autorización y de Recursos.
También encontré varias preguntas donde la respuesta fue "Bueno, pueden ser cuadros diferentes siempre que compartan el mismo origen de datos tokenStore". ¿En serio puede ser verdad? ¿Cómo podría funcionar esto para microservicios? Parecería una cosa realmente extraña que cada servicio de descanso necesitaría implementar su propio servidor de autorización OAuth.
Entonces, ¿cómo configuro la seguridad de Oauth2.0 para los puntos finales de reposo de arranque de resorte que se refieren a un servidor de autorizaciones remoto (posiblemente ni siquiera escrito con Spring)?
Hay algo llamado RemoteTokenServices que parece prometedor pero que en realidad no está documentado.
No es realmente cierto que ambos tengan que compartir la misma base de datos, siempre que el servidor de recursos tenga alguna forma de validar que el token de acceso sea genuino (fue emitido por el servidor de autorizaciones) y también una forma de decodificarlo (puede necesitar saber qué alcances que concede, por ejemplo). La especificación OAuth2 no dice nada sobre cómo se logrará esto.
Si el recurso está en el mismo proceso que el servidor de autorización, compartir los datos es una opción fácil. De lo contrario, necesita alguna forma de traducir el token. Si el token es solo una cadena opaca de bytes aleatorios, obviamente tiene que cambiarlo por la información real. Esto es lo que hace RemoteTokenServices
. El servidor de autorización expone un /check_token
final /check_token
para permitir decodificar los tokens.
Una alternativa es codificar realmente la información en el token y hacer que el servidor de autorización lo firme digitalmente. El servidor de recursos puede decodificar y validar el token en sí mismo siempre que comprenda el formato.
Te recomiendo que consultes Cloudfoundry UAA, que proporciona un servidor de autorización que se implementa utilizando tokens JWT firmados (también expone el /check_token
final /check_token
). La descripción general de Tokens y los documentos API son probablemente un buen punto de partida.
RemoteTokenService
puede encontrar una muestra de trabajo de RemoteTokenService
.
Para obtener más información sobre check_token
api, puede consultar org.springframework.security.oauth2.provider.endpoint.CheckTokenEndpoint.java
En el extremo del servidor de recursos, OAuth2AuthenticationProcessingFilter
valida el token OAuth2 llamando OAuth2AuthenticationManager.authenticate()
método OAuth2AuthenticationManager.authenticate()
que realiza la llamada a RemoteTokenServices.loadAuthentication()
para validar el token del servidor de autenticación.