La configuración de seguridad estándar de FundeWebJS permite solamente validar los tokens JWT de OAUTH obtenidos desde micampus.

En ocasiones una API necesitará validar otro tipo de tokens OAUTH obtenidos desde otras aplicaciones, scopes u otros flujos OAUTH.
Por ejemplo: validación de tokens OAUTH del flujo CLIENT CREDENTIALS para la comunicación entre APIs FundeWeb y FundeWebJS.

Esta página trata sobre la configuración de nuestra API FundeWebJS para validar tokens con scopes diferentes a los recibidos desde micampus (scope: micampus), las respuestas que produce esa configuración en caso de recibir un token inválido y cómo personalizar esa respuesta.

Guía detallada


1. Configuración global de otros scopes en la aplicación

El primer paso para validar scopes diferentes en FundeWebJS es añadirlos a la property server.scopes del application.properties. Esta property ya está configurado para el scope "micampus".
Para añadir un scope nuevo, hay que ponerlo a continuación del existente separado por comas y con el prefijo "SCOPE_".

Por ejemplo: 

#Valida los scopes 'micampus' y 'miotroscope'
server.scopes=SCOPE_micampus,SCOPE_miotroscope

2. Configurar endpoints por scope

Con la configuración del punto 1 se configura TODA la aplicación para permitir tokens que contengan cualquiera de los scopes configurados.
Esto significa que un token obtenido desde micampus por cualquier usuario sería válido para acceder a cualquier endpoint.
Si hemos tenido que configurar varios scopes, lo normal es que está situación sea no deseada (no queremos que cualquier token sirva para acceder a endpoints que requieran un nivel diferente de acceso).

En este paso se explica cómo configurar nuestra aplicación para securizar diferentes endpoints con scopes distintos.
Existen dos alternativas:

- Configurar los mvcMatchers en el SecurityConfig.
- Utilizar la anotación PreAuthorize en cada método Java de nuestro RestController.

Configuración de MvcMatchers


La primera forma de configuración es añadir un mvcMatcher en el método configure de nuestra clase "SecurityConfig". 
Se añade el mvcMatcher que capture la/s rutas/s a securizar con nuestro nuevo scope (antes del mvcMatcher configurado por defecto para private-apiPath) y se le añade .hasAuthority("SCOPE_miotroscope").

Ejemplo:

@Override
protected void configure( HttpSecurity http ) throws Exception {
	http.requestMatchers().antMatchers( "/public/**" ).and().requestMatchers().antMatchers( apiPath + "/**" ).and()
	.sessionManagement().sessionCreationPolicy( SessionCreationPolicy.STATELESS )
	.and().cors() 
	.and().csrf().disable().authorizeRequests()
	.mvcMatchers( "/public/**" ).permitAll()
	.mvcMatchers( apiPath + "**/mirecurso/misubrecursoconotroscope/**" ).hasAuthority( "SCOPE_miotrorecurso" )
	.mvcMatchers( apiPath + "/**" ).hasAnyAuthority( serverScopes ).anyRequest().authenticated()
	.and().addFilterAfter( loggingFilterBean(), BearerTokenAuthenticationFilter.class )
	.oauth2ResourceServer().jwt();
}


-- Respuesta de error --

Cuando llega una petición al endpoint securizado de esta forma con un token que no incluye el scope configurado, la librería spring-security-oauth2-resource-server toma el control y devuelve la respuesta de la siguiente forma: 


!!OJO¡¡ Como la librería spring-security-oauth2-resource-server toma el control del error, cualquier otro manejo de la excepción configurado según Manejo de Errores en FundeWebJS NO TENDRÁ EFECTO.


Para sobreescribir el comportamiento de la respuesta de error habrá que crear una clase AccessDeniedExceptionHandler propia y configurarla en el mismo método configure de nuesta clase "SecurityConfig" añadiendo el exceptionHandling de esta forma: 

...
.mvcMatchers( apiPath + "**/mirecurso/misubrecursoconotroscope/**" ).hasAuthority( "SCOPE_miotrorecurso" )
.mvcMatchers( apiPath + "/**" ).hasAnyAuthority( serverScopes ).anyRequest().authenticated()
.and().exceptionHandling().accessDeniedHandler( new MiOtroAccessDeniedHandler())
.and().addFilterAfter( loggingFilterBean(), BearerTokenAuthenticationFilter.class )
.oauth2ResourceServer().jwt()
...


Tomar de ejemplo la clase BearerTokenAccessDeniedHandler (handler por defecto de spring-security-oauth2-resource-server) para crear nuestra clase AccessDeniedExceptionHandler propia.














También puede ser conveniente usar paneles visuales para comunicar información relacionada, sugerencias o aspectos que los usuarios deban tener en cuenta.

Artículos Relacionados

Aquí aparecen artículos relacionados sobre la base de las etiquetas que usted seleccione. Haga clic para editar la macro y añadir o modificar las etiquetas.



Incidencias similares