Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 3 Siguiente »

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.


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

LAGAR - ejemplo de logs con Token Personificado.

Artículos Relacionados



  • Sin etiquetas