En la capa de presentación para las aplicaciones cliente, la Web API, existen 4 controladores que se encargan del manejo del módulo de seguridad: Indentity Controller, Tenants Controller, Error Logs Controller y Security Settings Controller. 

De estos controladores, el principal, y el que maneja el mayor número de funcionalidades es el Identity Controller. Además, este controlador hace uso del Security Service implementado en la capa de negocio.

Una técnica recurrente en las solicitudes de los controladores que interactúan con la base de datos es envolverlas dentro de una transacción SQL, esto garantiza la consistencia de los datos en caso de que ocurra un error en el proceso de alguna de estas solicitudes. De ser así, la transacción se reversa con todos los cambios y vuelve al estado original.

A continuación, se describen algunos de los principales endpoints:

  • GetAll, entrega una lista con todos los usuarios, teniendo en cuenta del tenant que está realizando la solicitud, debido al filtro global que limita que los usuarios pertenezcan a ese tenant. 
  • GetUsersActivity, muestra la actividad del usuario, y es lo que en el ERP se refleja como log activity: inicio sesión, cerro sesión, etc.
  • GetUsersActions, son todas las acciones del usuario, es la bitácora donde se registran acciones como: creó un recurso, modificó un recurso, etc.
  • GetAllIssues, es una tabla que tiene el log activity del sistema, inicio sesión, cerro sesión, etc.
  • GetAllLockedUsers, como su nombre lo indica, devuelve todos los usuarios bloqueados.
  • Register, crea y registra un nuevo usuario en el sistema siguiendo estos pasos:

Primero, se verifica que no se repitan el mismo nombre de usuario y código de usuario, se utiliza al UserManager el cual es un servicio que provee de funcionalidades relacionadas a los usuarios del sistema. Este servicio es propio del Identity Model. También permite agregar o sobrescribir funcionalidades.

Segundo, se verifica que no exista usuario con el mismo correo electrónico, a no ser que sea un usuario genérico, en ese caso se le asigna el correo electrónico de mesa de ayuda.

Tercero, se verifica que no se le asignen al usuario roles que no existan o no se encuentren registrados.

Cuarto, se le asignan las sucursales a las cuales va a tener acceso con ese usuario.

Finalmente, se procede a la creación del usuario y es insertado a la base de datos para su registro. Luego, se hace el hash de la contraseña, es decir, se la encripta y además se la agrega al historial de contraseñas.

Se genera un resultado de identificación, lo que básicamente devuelve un token que identifica ese usuario en el momento que se lo registra.

Se agrega un registro en el log indicando que se ha creado un nuevo usuario. Si todo funcionó, se da commit a la transacción y todos estos cambios quedan asentados en la base de datos.

  • Login, inicia sesión para el usuario que intenta acceder, esta solicitud se envía al servicio de seguridad siguiendo los siguientes pasos:

Primero, verificar si el usuario existe y que el usuario no esté desactivado. De no ser así, se presenta un mensaje genérico “usuario o contraseña incorrecta”, que por seguridad no revela ningún detalle sobre esta validación.

Segundo, verificar si el usuario tiene asignación en la sucursal que desea acceder. Esta validación se hace a través del servicio de usuario, y se busca un match dentro de la tabla de enlaces usuario-sucursal. En caso de que no se encuentre ningún match entre el usuario y la sucursal, se presenta un mensaje explicito indicando este error. Si el usuario es administrador raíz, puede acceder a cualquier sucursal.

Lo siguiente es validar que el usuario no este bloqueado y que la contraseña ingresada esté correcta. Para esto se compara los hashes de la contraseña ingresada y la registrada, esto significa que la contraseña en la base de datos en ningún momento es desencriptada. Si esta validación falla, se aumenta en una unidad el contador de intentos de acceso fallidos hasta llegar al máximo, en tal caso el usuario es bloqueado. También se verifica si la contraseña no está caducada, en caso que esa opción haya sido activada por el administrador del sistema.

- Manejo de sesiones –

A pesar de que las REST API no deben manejar sesiones, debido a que se consideran una tecnología de tipo stateless, ya que toda la información de un request debe ir incorporada en el mismo request, para esta solución se identificó posteriormente como un requerimiento indispensable del sistema el manejo de sesiones.

Una vez el usuario ha pasado por todas las validaciones de seguridad, se procede a abrir una nueva sesión. Esta sesión cuenta con unos parámetros que son inicializados en el momento de su creación, estos incluyen: el usuario que creó la sesión, la MAC del dispositivo desde donde fue creada, ID único de esa sesión, estado de activación, fecha en que fue creada, fecha de expiración, información del tenant al que pertenece esa sesión.

Luego se realiza el manejo de licencias, para esto es importante conocer cuantas sesiones del tenant se encuentran activas, ya que el número de sesiones activas máximas por tenant debe estar acorde del tipo de licencia que haya comprado. Esta validación se realiza usando el servicio de tenants y este a su vez utiliza el servicio de identificación para agrupar todas las sesiones activas de un tenant en específico.

Además del número de sesiones permitidas por licencia, también se valida el número de sesiones simultáneas permitidas por usuario, parámetro modificable desde el módulo de seguridad. El administrador raíz solo puede tener una única sesión activa a la vez.

Si se logra iniciar una sesión correctamente, se reinicia el contador de intentos de acceso fallidos, y se actualiza la fecha del último acceso del usuario. Se genera también el token de acceso que identifica al usuario con el sistema. Este token es una cadena de caracteres que contienen información del usuario encriptada para que pueda conectarse al sistema, tiene tiempo de expiración, y por este motivo es guardado junto con un token de refrescamiento.

Finalmente se devuelve una respuesta que incluye los roles, el nombre de usuario, tenant, y otros parámetros que indican si se requiere un cambio de contraseña, o si se ha hecho login de un dispositivo nuevo. Se devuelve también el ID de la sesión, con el cual la aplicación cliente constantemente va refrescándola para mantener activa.

Si todo este proceso salió bien, se da por completado el proceso de login del usuario al sistema.

  • Logout, cierra la sesión que tenga el ID que recibe de parámetro.

Se fija la fecha de expiración en ese preciso momento y se marca como inactiva la sesión, luego se actualiza esos cambios en la base de datos.


En resumen, la estructura que se sigue en este módulo es: los controladores llaman a los diferentes servicios de negocio como seguridad y tenants, estos servicios a su vez hacen uso del Identity Model, como las funcionalidades del UserManager, y este a su vez utiliza los repositorios de datos de usuarios, errores, etc.


Created with the Personal Edition of HelpNDoc: Single source CHM, PDF, DOC and HTML Help creation