Servidor - Autenticación - Factoría Login y lógica BD vs LDAP

zahori-io / zahori-server

GNU Affero General Public License v3.0

3 stars 1 forks source link

Servidor - Autenticación - Factoría Login y lógica BD vs LDAP #47

Open zahori-io opened 1 year ago

zahori-io commented 1 year ago

Implementar la factoría de Login y la lógica necesaria para realizar el proceso contra la BD (actual) y/o un LDAP corporativo

panel-jbabio commented 1 year ago

Tras revisar el mecanismo de autenticación configurado del aplicativo, se ha detectado que se está haciendo uso de "WebSecurityConfigurerAdapter" que está deprecado desde la versión 2.7.0. Por lo que primeramente se realizará una refactorización del mecanismo de autenticación para actualizarlo.

panel-jbabio commented 1 year ago

La fase de autenticación se ha completado, pero queda el tema de la autorización. Hasta ahora los roles se obtienen de la BBDD, pero al enganchar un LDAP surge el siguiente problema:

El mecanismo de autenticación verifica con el LDAP que el usuario y contraseña son válidos, pero ese usuario no existe en la BBDD, por lo que hay dudas de si debería proporcionarle token (lógicamente sin roles vinculados).
En el caso de que se decida proporcionar token, puede que interese crear al vuelo el usuario en la BBDD con un rol por defecto, pero esto abriría la puerta a todo el mundo de la plantilla del cliente.

davidvazqu3z commented 1 year ago

Muchas gracias @panel-jbabio! Para el problema que comentas tenemos pensado lo siguiente:

Si la autenticación por LDAP está activada y un usuario es la primera vez que inicia sesión en Zahorí efectivamente ese usuario no estará registrado en la base de datos y por tanto no tendrá asignado ni roles, ni grupos, ni permisos.
Para estos casos el usuario podrá hacer login y acto seguido se le mostrará un mensaje en la web inidicándole que contacte con el administrador para que le asigne el rol y grupos que le corresponden.
El token que se le asigne no tendrá permisos para acceder a ninguna funcionalidad ni ver ningún dato hasta que el administrador le asigne rol y grupos (esta asignación de roles, grupos y permisos se implementará en otra tarea específica).

panel-jbabio commented 1 year ago

OK, de acuerdo!

Para facilitar al administrador esa gestión de grupos y roles del nuevo usuario, ¿la información del login de usuario se quiere que se almacene para que el administrador sepa cuantos y cuales han intentado acceder para que sepa que tiene que gestionarlos?

Lógicamente estos nuevos usuarios que acceden autenticando con LDAP no podrán autenticarse contra BBDD, por lo que se meterá un campo de "tipo de autenticación" para diferenciarlos.

davidvazquezsec commented 1 year ago

Sí, hace falta añadir un campo authentication_type al usuario (aunque seguramente en una próxima fase irá en una tabla aparte, pero de momento nos vale).
En lo referente a facilitar la labor del administrador: de momento no hace falta añadir campos adicionales, ya que se podría saber a que usuarios falta asignar permisos sabiendo el tipo de autenticación del usuario y que además no tiene asignados roles aún.