Cuando se hace uso del mecanismo de Token Personificado es obligatorio que los logs enviados a LAGAR contengan información sobre el usuario real y el usuario personificado.
Para ello hay que realizar la siguiente configuración:
Guía detallada
1. Configurar dependencia en pom.xml
Si alguna de las configuraciones ya existe, no hace falta volver a declararla. En este caso, si en local teníamos descargada una versión antigua, haría falta hacer un maven update project para actualizar la librería.
- Añadir property para la versión:
<properties> ... <fdwjs.version>[1.0.0,)</fdwjs.version> ... </properties>
- Añadir dependencia:
<dependency>
<groupId>es.um.atica.fundewebjs.fundewebjs-api</groupId>
<artifactId>fundewebjs-api-components</artifactId>
<version>${fdwjs.version}</version>
</dependency>
- Añadir repositorio maven:
<repositories> ... <repository> <id>fundewebjs.archiva.atica.umu.es</id> <name>ATICA - UMU Repository - FundeWebJS</name> <url>https://archiva.um.es/archiva/repository/FundeWebJS/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> ... </repositories>
2. Cambios en Clase Application
Para que Spring-Boot localice los componentes declarados en la librería del paso anterior, es necesario indicarle el paquete que ha de escanear.
Para ello hay que modificar la clase Application y añadir el parámetro scanBasePackages a la anotación @SpringBootApplication:
Ejemplo:
@SpringBootApplication( scanBasePackages = {
"es.um.atica.[PAQUETE_BASE_APLICACION]", "es.um.atica.fundewebjs"
} )
public class SampleApplication {
3. Configurar filtro
Una vez configurada la dependencia, es necesario configurar el filtro que añade los usuarios a los logs.
En el fichero SecurityConfig (si se ha seguido la página Configuración de proyectos Spring Boot para FundeWebJs) :
- Inyectar el filtro FundeWebJSLoggingAuthorizationFilter :
@Bean
public FundeWebJSLoggingAuthorizationFilter loggingFilterBean() {
return new FundeWebJSLoggingAuthorizationFilter();
}
- Añadir el filtro recién inyectado a la configuración de seguridad para que se ejecute después del filtro BearerTokenAuthenticactionFilter:
... .addFilterAfter( loggingFilterBean(), BearerTokenAuthenticationFilter.class ) ...
Ejemplo de método configure completo:
@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( apiPath + "/public/**" ).permitAll()
.mvcMatchers( apiPath + "/**" ).hasAnyAuthority( serverScopes )
.anyRequest().authenticated().and()
.addFilterAfter( loggingFilterBean(), BearerTokenAuthenticationFilter.class )
.oauth2ResourceServer().jwt();
}
Depende del momento de implementación del Login con Oauth en nuestra aplicación, es posible que la configuración deba realizarse en el fichero SecurityConfigOauth.
El filtro debe añadirse siempre antes de la configuración oauth2ResourceServer().jwt(), independientemente del fichero en el que esté.
Puede verse un ejemplo de esta configuración en el proyecto API Base.
Resultado
Una vez realizada esta configuración, todos los logs que se pinten en nuestros servicios, cuando se haga uso de un Token Personificado, contendrán los siguientes campos:
log_processed.mdc.UMU-Token-Subject => Usuario personificado con el que se accede a los servicios.
log_processed.mdc.UMU-Token-OriginalSubject => Usuario real que realiza las peticiones.
