...

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

La librería fundewebjs-security contiene un fichero FundeWebJSSecurityConfig por defecto. Para utilizar otra configuración hay que realizar los siguientes pasos:

1. Si no existe en nuestro proyecto, crear una clase SecurityConfig.java nueva a partir del código de FundeWebJSSecurityConfig (ubicada en la librería fundewebjs-spring-boot-starter). Del código de esta clase, quitaremos esta línea:

   Bloque de código
   @ConditionalOnExpression( "${fdwjs.starter.cors.enable:true}" )

2. En el application.properties (de local y de los entornos en Helm Chart), añadir la siguiente property:
   
   

   Bloque de código
   //Deshabilita SecurityFilterChain por defecto fdwjs.starter.security.enable=false

   
   

A continuación se detallan las configuraciones específicas para autorizar por scopes:

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

El primer paso La primera forma para validar scopes diferentes en FundeWebJS es añadirlos a la property server.scopes del application.properties. Esta property ya se encuentra configurada por defecto 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: 

...

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 apartado 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.

2.1 Configuración de MvcMatchers

La primera forma de configuración es añadir un mvcMatcher en el método configure filterChain 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").

...

@Override
protectedpublic voidSecurityFilterChain configurefilterChain( HttpSecurity http ) throws Exception {
	http  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_miotroscope" )
	.mvcMatchers( apiPath + "/**" ).hasAnyAuthority( serverScopes ).anyRequest().authenticated()
	.and().addFilterAfter( loggingFilterBean(), BearerTokenAuthenticationFilter.class )
	.oauth2ResourceServer().jwt(); 	

     return http.build();
}

-- Respuesta de error --

Cuando llega una petición a el/los endpoints que concuerdan con la ruta del mvcMatcher y un scope inválido , la librería spring-security-oauth2-resource-server toma el control y devuelve la respuesta de la siguiente forma: 

...

2.2 Configuración con PreAuthorize

La segunda forma para configurar endpoints y securizarlos por scope es utilizando la anotación de spring-security @PreAuthorize.

...