jokoframework / security Goto Github PK

Joko Security provee la capacidad de realizar autenticacion y autorizacion por medio de Tokens JWT

License: Apache License 2.0

Shell 2.80% Java 97.20%

security's Introduction

Joko Security

Joko Security provee la capacidad de realizar autenticación y autorización por .medio de Tokens JWT. Se puede utilizar de dos maneras, como un componente separado que emite tokens o embebido como una librería dentro de otra aplicación Web. Joko Security es una extensión de spring-security que permite trabajar con token de refresh, y acceso utilizando como formato de tokens JWT.

Configuración embebido en otra App

Configuracion de la Base de Datos

Joko-security necesita un repositorio de datos en el cual se almacenan datos que permiten realizar el proceso de autorización. El sistema utiliza JPA de una manera bastante agnóstica a la BD. Sin embargo, actualmente solamente está probado con PostgreSQL 9.4

Escenario embebido en otra aplicacion

Una opción es utilizar Joko-security embebido dentro de otra aplicacion. En este caso el repositorio de datos debe tener la estructura de tablas que Joko esta esperando. Si el repositorio de datos se inicializa con liquibase, entonces todo el contenido para la creacion de la estructura necesaria se encuentra en: ./db/liquibase/db-changelog-evolucion.xml

Este archivo puede ser referenciado dentro del ciclo de actualizacion de la BD en el proyecto que incluya a joko-security como librería.

Inicio desde .sql

El inicio mas sencillo es correr el script .sql correspondiente a la BD que utiliza. Estos scripts se encuentran en:

/db/sql-initialization

Configuracion de su propia BD

En Joko poseemos un conjunto de scripts que nos permiten automatizar el ciclo de vida de una aplicación. Con esto se puede crear facilmente toda la BD desde la linea de comandos. Para actualizar hay que seguir los siguientes pasos:

Step 1) Crear el directorio PROFILE_DIR

El directorio de profile contiene el archivo application.properties con la configuracion necesaria para lanzar la aplicacion spring-boot.

La convencion utilizada es tener un directorio, dentro del cual existan varios PROFILE_DIR segun se requiera. Por ejemplo:

/opt/joko-demo/dev
/opt/joko-demo/qa

En el anterior ejemplo existen dos PROFILE_DIR dentro del joko-demo, el primero para development y el segundo con datos de quality assurance.

Obs.: Un archivo de ejemplo para el application.properties se encuentra en src/main/resources/application.properties

Step 2) Configuración del archivo "development.vars"

Se debe configurar el archivo "development.vars", que servirá para la ejecucion de liquibase. Este es un archivo bash que debe tener dos variables:

MVN_SETTINGS: Archivo de configuracion de perfil Maven. En caso de utilizar el Artifactory interno, sería el recien descargado. Ej. $HOME/.m2/settings.xml
PROFILE_DIR: Directorio de perfil creado en el punto inicial. Ej. /opt/joko

Un ejemplo de este archivo se encuenta en src/main/resources/development.vars.

Se recomienda que este archivo esté fuera del workspsace en el directorio padre de los PROFILE_DIR. Ejemplo: /opt/joko-security/. Este directorio es lo que se llama "ext.prop.dir" en las siguientes secciones.

Step 3) Configuración de variables de entorno

Exportar variable, desde la terminal:

  $ export ENV_VARS="/opt/joko-security/development.vars"

Obs.: El truco es tener varios archivos profile.vars y cada uno apuntando a un PROFILE_DIR diferente.

Step 4) Ejecutar Liquibase.

Crea la schema de cero.

  $ ./scripts/updater fresh

(Re)Inicializa datos básicos

  $ ./scripts/updater seed src/main/resources/db/sql/seed-data.sql

OJO:

El parámetro "fresh" elimina la base de datos que está configurada en el application.properties y la vuelve a crear desde cero con la última versión del schema
El parámetro "seed " carga datos indicados en el archivo , para los casos en que se ejecute "fresh" siempre debe ir seguido de un "seed" con el archivo que (re)inicializa los datos básicos del sistema
Los datos básicos del sistema estan en dos archivos: ** seed-data.sql: Todos la configuracion base que es independiente al ambiente ** [ambiente]-config. Por ejemplo: dev-config.sql . Posee los parametros de configuracion adecuados para el ambiente de desarrollo. Tambien existe qa-config y prod-config

Para correr el liquibase en modo de actualización ejecute:

  $ ./scripts/updater update

Conceptos de token

Un token es un permiso particular que garantiza al poseedor acceso a ciertos recursos. Los tokens son firmados por joko-security con una clave secreta, por lo tanto no pueden ser alterados. Esto permite a Joko-security realizar la validación en memoria de los tokens. Por ejemplo: un token extemporáneo se rechaza sin mayor chequeo.

Realizar las validaciones en memoria sin tener que tocar la base de datos permite a los sistemas que utilizan joko-security escalar con mayor rapidez al ser en gran medida stateless.

Los tokens en Joko siguen el standard :abbr:JWT (JSON Web Tokens) [#]_ . Existen dos tipos de token:

Refresh Token

Cuando un usuario se autentica al sistema recibe un refresh token. Este token permite al usuario acceder al sistema por un tiempo prolongado pero con pocos permisos de acceso. #### Un refresh token tiene información necesaria para obtener un nuevo access token. #### Un access token sirve para realizar operaciones.

Dependiendo del security profile el sistema devolverá un refresh token con mayor o menor tiempo de vida. Por ejemplo si el usuario accede desde una aplicación web se podría dar un token de una semana, y si accede desde la web en términos de horas. Si el usuario no utiliza la aplicación por 1 (una) semana, entonces necesitará realizar un nuevo login (esto es aceptable desde el punto de vista UX). Los refresh token son especialmente útiles para las aplicaciones móviles en las cuales es molesto pedir el usuario en cada momento la autenticación.

##Guardar el token de refresh de manera segura

En el caso de una aplicación móvil se tendría que guardar en el key store, y en el caso de una aplicación Web en los :term:cookies (NO guardarlos en WEB storage)

Access Token

Un :term:access token permite al usuario realizar todas las operaciones que su perfil permita.

Un token de acceso tiene un tiempo de vida corto, y la aplicación tendrá que renovar el token de acceso antes de que este fenezca.Esto crea la sensación al usuario de estar siempre conectado, mientras que también brinda un mayor nivel de seguridad.

Para mayor seguridad el token de acceso se debería de sostener solo en memoria.

Personalización

Joko-security no posee utilidad por si solo, sino que presenta un conjunto de genérico de funcionalidades que deben de ser especializadas y de esta manera permite ahorrar tiempo a un programador. Son dos las clases que se deben implementar para configurar joko-security, estas son: JokoAuthenticationManager, JokoAuthorizationManager, para configurar la autenticación y la autorización respectivamente.

JokoAuthenticationManager

Para determinar si ciertas credenciales son o no correctas el sistema que utilice Joko-security debe extender JokoAuthenticationManager o la correspondiente clase de Spring org.springframework.security.authentication.AuthenticationManager. En el caso que se realice una especialización nueva la recomendación es utilizar JokoAuthenticationManager. La compatibilidad con spring debería de utilizarse solo para soportar AuthenticationManager que ya fueron anteriormente implementados.

JokoAuthorizationManager

Se debe implementar esta interfaz para:

Determinar las autorizaciones para un request en particular.
- Esto debe hacerse examinando el token y tratando de no tocar la BD en lo posible. Recordemos que este método será invocada con cada request.
Determinar los URLs a los que se tiene acceso en base a las autorizaciones
- Se configura utilizando spring-security con la ventaja de que joko ya realiza las configuraciones básicas requeridas en proyectos de este tipo.

Ejemplos

Se recomienda tomar como modelo de ejemplo el proyecto joko_backend_starter_kit

Obtener el jar

El proyecto no está publicado actualmente en ningún maven repository. Por lo tanto, se requiere bajar el código fuente y realizar la instalación del jar. En la instalación del jar se correran los Unit Tests por defecto, se debe prepara la BD como se define en la sección "Unit Tests"

mvn -Dext.prop.dir=/opt/joko-security/test -Dspring.config.location=file:///opt/joko-security/dev/application.properties install

Un archivo de ejemplo de application.properties puede obtenerse en src/main/resources/application.properties.example

Funcionalidades proveídas por Joko

Se listan a continuación las configuraciones básicas y funcionalidades proveídas por Joko:

Error básico de forbidden devuelve código de error 403 Forbidden.
Error básico al no estar autenticado devuelve código de error http 401 Unauthorized
Se pueden lanzar las excepciones JokoUnauthorizedException y
JokoUnauthenticatedException desde cualquier lugar, el sistema devolverá 403 y
401 respectivamente.
La configuración del tiempo de vida de los tokens es en base al security profile
Los tokens de refresh se pueden revocar
Configuracion de spring-security especializada para aplicaciones stateless

Unit Tests

joko-security cuenta con una clase que contiene tests unitarios, para las funcionalidades principales de módulo:

Creación de tokens
Parseo
Refresh

Se puede correr los tests mediante maven

Actualizar los datos de una BD fresca con: $ ./scripts/updater seed src/main/resources/db/sql/seed-test.sql
Correr MVN mvn -Dext.prop.dir=/opt/joko-security/dev -Dspring.config.location=file:///opt/joko-security/dev/application.properties test

Configuraciones

En esta sección describimos la configuracion que se debería de tener en cuenta para que funcione correctamente joko-security

Toda la configuración se realiza en el archivo application.properties y el archivo src/main/resources/application.properties contiene un ejemplo comentado con las opciones

Configuraciones Basicas

El sistema necesita un secreto para firmar los tokens. Este secreto puede ser guradado en dos lugares:

BD: Si se guarda en la Base de datos va a la tabla joko_security.keychain
FILE: Si va al filesystem se debe configurar la propiedad joko.secret.file

ATENCIÓN: Es MUY importante que este secreto no sea accedido por terceras personas. La recomendacion para esto es:

BD: En este caso asigne permisos a la tabla con solo lectura y solamente para el usuario que se utiliza en la aplicacion
FILE: Asigne permisos de lecutra y solo para el usuario que se utiliza al momento de levantar la aplicacion.

Obs.:En modo BD puede dejarse sin crear un archivo y el sistema va a crear un secreto la primera vez que se levanta.

Uso del OTP

Primeramente hay que ver si quiere registrar en el usuario la semilla que seria utilizada para generar el OTP que sera comparado con el OTP que ingresa:

Ingresar Semilla: si quiere ingresar una semilla, debe ir a la pagina https://freeotp.github.io/qrcode.html. En esa pagina debe completar los datos opcionales como el nombre de la cuenta relacionada a la semilla, y poner la opcion "TIMEOUT" para que funcione como Timed-OTP. Esta aplicacion genera un QR que debe ser escaneado por su telefono, utilizando el programa FreeOTP que se puede descargar para Android. La semilla solo se ingresa una vez por lo que en nuevos logins, el usuario solo debe completar el campo de "user" y "password", y eliminar el campo de semilla.
No ingresar una semilla: si no desea en el momento ingresar una semilla, puede simplemente eliminar el campo de "seed" y el token sera generado.

Luego de tener una semilla en la DB, se procede al siguiente paso, el cual tendran 2 opciones:

Sin semilla guardada: solo debe ingresar un "0" en la linea de OTP, si realmente no tiene una semilla guardada, entonces se le consedera el token, de lo contrario se le dira que el OTP assignado no concuerda con el OTP generado en el programa.
Con semilla guardada: en la aplicacion FreeOTP en el celular podra ver el codigo de 6 digitos que debe ingresar para el parametro de OTP en el servidor.

Configuraciones del POM file Asegurese que las versiones de las dependencias

en los archivos pom.xml tengan la misma version, esto le generara problemas a la hora de querer levantar el servicio.

Changelog

Para una descripcion detallada de las versiones ver el archivo de Changelog

security's People

Contributors

Stargazers

Watchers

Forkers

voluntadpear joaquinolivera danicricco bsandoval roskoff gabrielci codacy-badger mirtagonz alefq behemot011 marcosechague dyuko jorge683 matiasfare ncanatta fintechworks

security's Issues

Persistir información de los request originados por cada token/sesión

Un ingreso/login exitoso, genera un refresh_token que luego se utiliza para ralizar los demás requests REST.
El objetivo de este ticket, es almacenar en un esquema tipo master/detail todos los requests generados por ese refresh_token, con informaciones de auditoría obtenidas del request

Nro. de IP que genera el request
Nro. de IP de la cabecera X-Forwarded-For (si existe)
User Agent

Migrar a Spring Boot 2.x

Spring 1.x y las librerías de las que depende está dejando de tener soporte, como eso tiene sus implicancias de seguridad, e objetivo de este ticket es migrar a las librería de Spring Boot 2.x y Java 11.

Como administrador tengo servicios rest para un módulo de auditoría

El proyecto utiliza JPA para el manejo de persistencia, con el proveedor Hibernate.
Se desea contar con servicios rest que me permitan tener auditoría con Envers y consultar los cambios realizados a la tabla representada por TokenEntity

Consultar por un criterio. Ejemplos

/api/secure/tokens/history/revisions/{userId}
/api/secure/tokens/history/revisions/{remoteIp}

Descargar reportes en formato JSON o CSV

/api/secure/tokens/report?format=json
Parámetros comunes a ambos formatos
startDate: Fecha de inicio, formato ISO 8601 :2018-02-28T23:19:06+00:00
endDate: Fecha de fin, formato [ISO 8601]

joko-security ofrece un método para consultar las sesiones por usuario y fecha

El objetivo de este ticket es implementar el método getSessions para que retorne las sesiones por usuario y fecha. Este método ya existe pero no está implementado aún, o retorna una lista vacía siempre.

Mejorar documentación de la configuración

La idea es mejorar la documentación de la configuración. Por ejemplo hay dos opciones que son posibles y no están correctamente documentadas:

Documentar que se puede usar el secret en la BD
Documentar que la primera vez se genera la clave

JokoSecurity escribe una excepcion cuando un token expira

Cuando un token expira Joko security escribe una excepción como la siguiente:

2017-11-29 10:02:43.044 DEBUG 23946 --- [nio-8080-exec-2] i.g.j.s.springex.JokoSecurityFilter      : /api/clients/1542561/feeds/2017/11 from User-Agent: okhttp/3.3.1 Unable to authenticate class io.jsonwebtoken.ExpiredJwtException: JWT expired at 2017-11-28T22:17:26-0300. Current time: 2017-11-29T10:02:43-0300
2017-11-29 10:02:43.044 DEBUG 23946 --- [nio-8080-exec-1] i.g.j.s.springex.JokoSecurityFilter      : /api/clients/1542561/budget/2017/11 from User-Agent: okhttp/3.3.1 Unable to authenticate class io.jsonwebtoken.ExpiredJwtException: JWT expired at 2017-11-28T22:17:26-0300. Current time: 2017-11-29T10:02:43-0300
2017-11-29 10:02:43.045 TRACE 23946 --- [nio-8080-exec-2] i.g.j.s.springex.JokoSecurityFilter      : Token received: eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIxMDE1NTM2NDY3OTQyMTcxNSIsImV4cCI6MTUxMTkxODI0NiwiaWF0IjoxNTExOTA3NDQ2LCJqdGkiOiJVSkFDRUg3Sk1VSFk1N0JIU1FNUSIsImpva28iOnsidHlwZSI6IkFDQ0VTUyIsInJvbGVzIjpbIkVORF9VU0VSIl0sInByb2ZpbGUiOiJERUZBVUxUIn19.DrT4lsQfJXxVavm5joIDvp29DLeMmrYWiRzRuhjWEmr78_JKMxj1arrxDHgxVLxChTu4oeYBxDFPdd6HB_GoJw
2017-11-29 10:02:43.045 TRACE 23946 --- [nio-8080-exec-1] i.g.j.s.springex.JokoSecurityFilter      : Token received: eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIxMDE1NTM2NDY3OTQyMTcxNSIsImV4cCI6MTUxMTkxODI0NiwiaWF0IjoxNTExOTA3NDQ2LCJqdGkiOiJVSkFDRUg3Sk1VSFk1N0JIU1FNUSIsImpva28iOnsidHlwZSI6IkFDQ0VTUyIsInJvbGVzIjpbIkVORF9VU0VSIl0sInByb2ZpbGUiOiJERUZBVUxUIn19.DrT4lsQfJXxVavm5joIDvp29DLeMmrYWiRzRuhjWEmr78_JKMxj1arrxDHgxVLxChTu4oeYBxDFPdd6HB_GoJw
2017-11-29 10:02:43.046 ERROR 23946 --- [nio-8080-exec-2] i.g.j.s.springex.JokoSecurityFilter      : Error validando el token.

io.jsonwebtoken.ExpiredJwtException: JWT expired at 2017-11-28T22:17:26-0300. Current time: 2017-11-29T10:02:43-0300
	at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:365)
	at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:458)
	at io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:518)
	at io.github.jokoframework.security.util.SecurityUtils.parseToken(SecurityUtils.java:227)
	at io.github.jokoframework.security.services.impl.TokenServiceImpl.parse(TokenServiceImpl.java:322)
	at io.github.jokoframework.security.services.impl.TokenServiceImpl$$FastClassBySpringCGLIB$$b683a18c.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:282)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
	at io.github.jokoframework.security.services.impl.TokenServiceImpl$$EnhancerBySpringCGLIB$$8e6ca5e7.parse(<generated>)
	at io.github.jokoframework.security.springex.JokoSecurityFilter.validateToken(JokoSecurityFilter.java:97)
	at io.github.jokoframework.security.springex.JokoSecurityFilter.doFilter(JokoSecurityFilter.java:55)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:64)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:347)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:263)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:108)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:81)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)

Esto resulta muy inconveniente, puesto que no es un error y el log se va llenando de estas excepciones.

Evaluación de la causa

Examinando el código de Joko-security nos encontramos que en la clase JokoSecurityFilter (linea 72) se encuentra esta porción de código:

            } catch (IllegalArgumentException | JwtException var7) {
                String uri = httpRequest.getRequestURI();
                String userAgent = httpRequest.getHeader("User-Agent");
                LOGGER.debug(uri + " from User-Agent: " + userAgent + " Unable to authenticate " + var7.getClass() + ": " + var7.getMessage());
                LOGGER.trace("Token received: " + token);
                LOGGER.error("Error validando el token.", var7);
                return null;
            }

Como se puede ver la lina que imprime la excepción (var7) es la causante del problema. En mi opinión esto no debería de escribirse con un nivel tan alto de LOG (error actualmente) puesto que realmente no es un comportamiento erróneo del sistema, sino algo que naturalmente puede pasar. Esta excepción podría escribirse como máximo en TRACE.

Versiones afectadas

Todas, desde la actual (0.1.8) hacía atrás.

Solucionar los javadoc warnings

El proyecto al compilar con maven posee varios JavaDoc warnings. El objetivo de este ticket es limpiarlos:

[WARNING] Javadoc Warnings
[WARNING] /Users/danicricco/sources/joko/security/src/main/java/io/github/jokoframework/security/util/SecurityUtils.java:246: warning: no description for @param
[WARNING] * @param filePath
[WARNING] ^
[WARNING] /Users/danicricco/sources/joko/security/src/main/java/io/github/jokoframework/security/util/TXUUIDGenerator.java:188: warning: no description for @param
[WARNING] * @param l
[WARNING] ^
[WARNING] /Users/danicricco/sources/joko/security/src/main/java/io/github/jokoframework/security/util/TXUUIDGenerator.java:189: warning: no description for @param
[WARNING] * @param size
[WARNING] ^
[WARNING] /Users/danicricco/sources/joko/security/src/main/java/io/github/jokoframework/security/util/TXUUIDGenerator.java:190: warning: no description for @return
[WARNING] * @return

Fix snakeyaml security issues

To this date there's still no fix for: https://nvd.nist.gov/vuln/detail/CVE-2022-1471

There are still no fix for

https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.33

Currently it's being intentionally ignored in dependency-check exclusions

Como developer me gustaría un changelog

Yo estoy usando la versión 0.1.4.1 pero veo que la última versión es la 0.1.8. Sin embargo, no logro identificar cuales son los cambios entre las distintas versiones.

Me encantaría que exista un changelog, donde se pueda ver claramente la evolución del producto. Idealmente un release notes, donde podamos ver cual es la compatibilidad hacia atras del módulo

Corrección en el nombre de la columna "max_number_devices_user" de SecurityProfile.java

Existe una inconsistencia entre el nombre del atributo y el nombre de la columna para liquibase.
Ref:
https://github.com/jokoframework/security/blob/master/src/main/java/io/github/jokoframework/security/entities/SecurityProfile.java#L92

Objetivo: Consultar el nombre del atributo o la columna consultando el histórico del mismo y la necesidad real de la columna dentro del proyecto.

La tabla seed debe ir como evolución para el liquibase

Para poder migrar de una versión anterior, se debe colocar el cambio que agrega la tabla seed como evolución para el liquibase.

    <changeSet author="danicricco" id="1518643732286-101">
        <createTable tableName="seed"
                     schemaName="joko_security"
                     remarks="Guarda las semillas OTP">
            <column name="id" type="BIGSERIAL">
                <constraints nullable="false"/>
            </column>
            <column name="user_id" type="VARCHAR(255)"/>
            <column name="seed_secret" type="VARCHAR(255)"/>
        </createTable>
    </changeSet>
    <changeSet author="danicricco" id="1518643732286-102">
        <addPrimaryKey columnNames="id" constraintName="seed_pkey"
                       tableName="seed" schemaName="joko_security"/>
    </changeSet>

Se debe pasar ese changeset del inicial al evolución.

Reactivar el test TokenControllerIntegrationTest#requestingTokenInfoShouldReturnOk

El test TokenControllerIntegrationTest#requestingTokenInfoShouldReturnOk fue desactivado porque tiene un problema de compatibilidad de librerías. Como todos los demás test funcionan y el problema tiene que ver con una librería que se usa en test, se decidió momentaneamente desactivar la funcionalidad.

La librería se usa solo a nivel de test y se comprobó el correcto funcionamiento del sistema en general.

El objetivo de este ticket es resolver el problema de compatibilidad de librerías y volver a activar el test

Stacktrace del test en error

java.lang.NoClassDefFoundError: com/jayway/jsonpath/Predicate

	at org.springframework.test.util.JsonPathExpectationsHelper.<init>(JsonPathExpectationsHelper.java:61)
	at org.springframework.test.web.servlet.result.JsonPathResultMatchers.<init>(JsonPathResultMatchers.java:61)
	at org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath(MockMvcResultMatchers.java:192)
	at io.github.jokoframework.security.controller.TokenControllerIntegrationTest.requestingTokenInfoShouldReturnOk(TokenControllerIntegrationTest.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

Evaluación

Parece que la librería en cuestión es:

<dependency>
	    	<groupId>com.jayway.jsonpath</groupId>
			<artifactId>json-path</artifactId>
			<version>0.8.1</version>
			<scope>test</scope>
		</dependency>

Se probó rápidamente cambiar a la última versión 2.4.0 y no se tuvo éxito

La tabla audit parece no tener utilidad. Evaluar deprecarla

La tabla audit parece no tener utilidad alguna. Para emitir la opinión me paso en lo siguiente:

Audit solo se llena desde un Controller en particular (AuditSessionController)
Es decir, el cliente tiene que explícitamente llamar a este URL para ser auditado. Sin comprender el caso de uso que motivó a su creación, parece no tener sentido.

Si se desea auditar la emisión de tokens, esto no debe ser voluntario. Un cliente podría llamar, obtener un token y decidir no llamar al método de auditoría. La auditoría debería de darse como consecuencia de que se emitió un token.

La información que se almacena en audit ya está en la tabla tokens.
La información que se está pretendiendo guardar desde "audit" ya se encuentra en la tabla "tokens"

Propuesta

Mi propuesta concreta es eliminar la tabla Audit y los objetos que se construyen encima de ella.

No se esta generando un secreto en el caso que no haya uno todavia en la BD

Cuando está puesta la propiedad para que el secreto se guarde en la BD (Tabla keychain) se deberia de generar automaticamente el secreto de no existir (Según el archivo RUN.md), pero esto no esta ocurriendo, simplemente revienta porque no logro obtener el keychain cuando se inicializa el proyecto.

(Como Workaround se puede insertar a mano en la BD un Keychain con id=1 y un string al azar como secreto)

Implementar un generador de semilla OTP con QRCode

Se debe agregar al proyecto, servicios que permitan generar una semilla aleatoria con su respectivo QRCode que permita tener códigos para utilizar la aplicación FreeOTP mobile como un factor de autenticación.

Se debe utilizar el proyecto, https://freeotp.github.io/ y asociar el código a una sesión autenticada mediante Joko Security y JWT.

Publicar la librería como github package

Cambiar el tipo de datos de las PK a bigserial

En el archivo de changelog de liquibase; se debe cambiar los tipos de datos de las PK a bigserial, y eliminar la creación de secuencias que existen actualmente.
Verificar que los test unitarios sigan corriendo en una base de datos recién creada.
Aumentar el nro. de release en el pom.xml .

Resolver vulnerabilidad con puntaje CVSS >= 8.0 que impide construir el .jar

Aparecio una vulnerabilidad relacionada a Gradle que impide construir el proyecto

Dependencias afectadas:

Información sobre el CVE-2019-15052:
https://nvd.nist.gov/vuln/detail/CVE-2019-15052

Persistir datos del mapa custom en base de datos

Actualmente Joko Security recibe un JSON para la autenticación del formato:

{
  "username":"sodep",
  "password":"PONER_AQUI_EL_PASSWORD",
  "custom": {
    "codigoEmpresa":123,
    "codigoSucursal": 2,
    "codigoCaja":982341
  }
}

pero el mapa custom no es persistido en la base de datos.
El objetivo del ticket es que esta información sea almacenada en una columna y pueda ser recuperado en una instancia cualquiera de un token.

Agregar Continuous Integration (CI)

Agregar una tarea de Travis o CircleCI que ejecute los unit tests como requisito para el merge del proyecto.

Se debe eliminar el proyecto de ejemplo; actualizar el Readme y hacer referencia al joko_backend_starter_kit como el proyecto de referencia/ejemplo.

Los unit tests deberían correr con la base de datos H2 así como lo hace ahora el proyecto de Backend

El nombre del schema es parametrizable en tiempo de compilacion

Necesitamos generar los entities y que el nombre del schema pueda ser parametrizable en tiempo de compilación. La idea es poder utilizar ciertas base de dato que no soportan el concepto de schema.

Para solucionar el ticket se debería de tener dos elementos:

Incluir un preprocesador para cambiar el schema de acuerdo al maven profile.
Tener la capacidad de regenerar el liquibase para que se use el nombre dinámico.

La clase Application.java tiene configuración no necesaria para librerías empaquetadas como JAR

En concreto, la documentación de Spring Boot menciona algunos requisitos que debe tener el Application.java para que un proyecto Spring Boot sea deployable como war.

Joko security no necesita cumplir esos requisitos, como por ejemplo extender de SpringBootServletInitializer.

Se debería modificar y quitar estas configuraciones, teniendo en cuenta que el objetivo de este proyecto es poder ser utilizado como librería empaquetada como JAR en otros proyectos.

Problemas similares pueden encontrarse aquí: spring-projects/spring-boot#5033

Como usuario deseo tener la applicación de ejemplo funcionando con base de datos H2

Los objetivos del presente issue:

Crear un tag con el relese actual
La aplicación ejemplo funciona con la última versión estable de Spring Boot Web Starter (a la fecha 1.5.9)
Se corrige el #6
Las instrucciones de ejemplo y la configuración default (application.properties) utiliza la base de datos H2 con generación automática mediante JPA de las tablas
Existe un Postgresql.README que explica cómo configurar en ese tipo de motor de BD

Se debe crear un fork desde la rama develop y una vez concluído el aporte, solicitar el pull request.

El index.html no corresponde al proyecto

El archivo que encuentra en src/main/resources/public/index.html no corresponde al proyecto. Esto resulta muy inconveniente puesto que al ser incluido en un proyecto que no posee "index", es la página que se termina mostrando.

Actualizar las dependencias a sus últimas versiones

Se debe actualizar las dependencias del pom.xml y aumentar el número de release para security.