Permisos de usuarios en aplicación web y servicios web

La aplicación web de LibreDTE utiliza el framework SowerPHP. Que, entre otras funcionalidades, tiene una extensión que permite la administración de usuarios y los permisos de acceso de estos usuarios a los recursos.

Los permisos básicamente se definen por un recurso al que se desea acceder, por ejemplo:

  • /sistema Es un recurso que dará acceso específicamente a la URL /sistema, y nada más.
  • /sistema/* Es un recurso que dará acceso a la URL /sistema/ y todo lo que esté bajo esa URL.
  • /sistema* Este caso no es igual al anterior, ya que podrá incluir URL del tipo /sistemas/* que podrían ser para otro propósito.
  • mirecurso Es un recurso llamado mirecurso y no necesariamente es una URL.

Como podemos ver, hay básicamente 3 casos:

  • URL específica.
  • URL con comodín.
  • Recurso específico.

Donde el más usado es el caso de URL con comodín.

Los permisos se asignan a grupos de usuarios, no a usuarios. De esta forma se tiene lo siguiente:

El modelo relacional real es un poco diferente, pero es la misma idea.

Este esquema permite una definición de permisos muy precisa a nivel de cada recurso que se desea usar. Sin embargo, hacer eso, puede resultar muy tedioso y lento, ya que definir cada URL a la que se desea acceder requiere trabajo y alto mantenimiento al ir creando recursos nuevos.

En LibreDTE se optó por algo sencillo, por defecto, hay un grupo de permisos asignados a los usuarios, el cual es fijo y no permite, actualmente, modificaciones.

Voy a hablar del grupo dte_plus por ser el grupo principal de LibreDTE y el mismo grupo que se recomienda usar en instalaciones locales, aunque esto no es obligatorio. Ya se podrán imaginar que cada instancia puede definir la granularidad que se quiera para definir los permisos. Tampoco voy a mencionar otros grupos, en www.libredte.cl existen varios servicios que usan sus propios grupos para los permisos, pero con dte_plus se entenderá la idea y el resto es análogo.

Grupo dte_plus y permisos de usuario

Los grupos tienen los permisos, y los grupos se asocian a usuarios, no a empresas. Esto es algo que se arrastra desde el framework y se mantuvo así. Esto genera la primera situación: no es posible habilitar servicios diferentes en empresas diferentes que están bajo el mismo usuario. Dicho de otra forma, un usuario que tenga habilitados ciertos permisos, los tendrá habilitados en todas las empresas que tenga registradas.

Otro punto importante de www.libredte.cl es “a quién” se asignan los permisos, o en otras palabras, “a quién” se le activa un servicio determinado. La respuesta: al usuario administrador principal de la empresa.

Recordemos, que el usuario administrador principal es el usuario que tiene registrada la empresa a su nombre:

Si “usuario” tiene valor, la empresa está registrada en LibreDTE

Por lo anterior, si tenemos una empresa que tiene usuarios autorizados, estos usuarios, por norma general, no tendrán activo un servicio. O sea, no tendrán un grupo asociado que represente ese servicio y por ende no tendrán permisos asociados.

En la práctica, una cuenta de usuario “normal” tiene acceso a muy pocos recursos:

Permisos por defecto. Sólo se tiene acceso al grupo usuarios

Si vemos a este usuario, no tiene permisos para ingresar a /dte/dashboard permiso necesario para ingresar al Dashboard del módulo de facturación. Tampoco tiene permiso para una URL similar con comodín.

¿Entonces? ¿Cómo puede este usuario acceder al servicio que tiene la empresa contratado?

Pedir permisos prestados

La solución es simple: pedir permisos prestados al usuario que si tiene activado el servicio. Esta opción partió como una idea simple y se ha ido mejorando con los años la funcionalidad para adaptarse a diferentes escenarios.

Por defecto, cuando un administrador de la empresa autoriza a un usuario a trabajar con la misma, le indica que rol tendrá. Actualmente en la versión oficial los roles son:

  • admin: Administrador (Acceso a todos los módulos. Incluye además editar empresa y otros usuarios, respaldos, descargar CAF, corregir Track ID)
  • dte: Módulo facturación electrónica (Emisión de DTE, recepción, informes y libros de compra/venta)
  • lce: Módulo contabilidad electrónica (Asientos contables, libro diario, libro mayor y balance general)
  • rrhh: Módulo recursos humanos (Mantenedor de empleados y liquidaciones de sueldo)
  • inventario: Módulo inventario (Inventario de mercaderías y activos fijos)
  • crm: Módulo gestión de clientes (Mantenedor de clientes, fidelización, estadísticas)

Donde cada rol se corresponde con uno o más grupos de usuarios. Los que a su vez tienen asociados los permisos reales.

Entonces, cuando un usuario autorizado que tiene el rol rrhh selecciona el contribuyente en el Dashboard Principal de LibreDTE se busca qué permisos sobre recursos tiene ese rol y si el usuario principal los tiene, se copian temporalmente al usuario autorizado. Todo esto se hace en caché y en la sesión activa, no se modifica nada en la base de datos.

De esta forma, el usuario “se hace pasar por otro”, específicamente por el usuario administrador principal. Aunque, mantiene sus datos de usuario, lo que se copia son sólo los recursos a los que se tiene acceso. Con esto se logra que un usuario autorizado pueda acceder a los recursos que el administrador haya permitido y que a su vez el administrador principal tenga acceso.

Ok… ¿y en los servicios web cómo funciona?

Ahora la parte realmente interesante, todo lo anterior es algo antiguo, conocido, o al menos, ya usado por los usuarios.

Los servicios web, hasta hace pocos meses, sólo funcionaban si el usuario que se autenticaba en los servicios web era el que tenía los permisos. Dicho de otra forma, sólo podían consumir los servicios web los usuarios principales que tenían el grupo dte_plus asignado.

Esto era algo malo, porque generaba lo siguiente:

  • Sólo se podía usar el usuario principal en los servicios web.
  • Si en nuestro sistema que conectamos con LibreDTE teníamos múltiples usuarios no podíamos reflejar eso mismo en LibreDTE para saber, por ejemplo, quien creó un documento.
  • Si queríamos usar una aplicación conectada había que estar compartiendo las credenciales entre todos los usuarios.

El último punto, específicamente con el caso de una aplicación móvil, fue lo que motivó en marzo de 2020 un cambio.

Para la aplicación móvil de LibreDTE en Android se necesitaba que cada usuario autorizado pudiera consumir los servicios web con su propio usuario. La solución fue replicar lo que hacía la plataforma web, pedir permisos prestados.

En resumen, para trabajar vía servicios web con un usuario que, por defecto, no tiene permisos para acceder a los servicios web debemos pedir prestados los permisos al usuario principal. Siempre y cuando estemos autorizados, podremos usar esos permisos y acceder a los recursos de los servicios web.

¿Cómo se hace? Fácil, al consumir los servicios web se debe pasar la variable _contribuyente_rut agregada a la URL con el valor del RUT del contribuyente con el que vamos a trabajar.

Por ejemplo, para crear un DTE temporal de la empresa 76.192.083-9 con un usuario autorizado que originalmente no tiene acceso a los servicios web, pero donde estamos autorizados por el administrador a trabajar, debemos consumir esta URL:

https://libredte.cl/api/dte/documentos/emitir?_contribuyente_rut=76192083

Al hacer eso, nuestro usuario, tomará los permisos que tengamos autorizados en la empresa y con esos accederá al servicio web.

Esta opción es exclusiva de los servicios en www.libredte.cl Ya que la forma descrita, de cómo operan los permisos y asignación según servicios es exclusiva de la versión oficial. Otras instancias pueden tener otras reglas, o incluso permitir el acceso a todos los servicios web sin restricción.

¿Tiene dudas con este tipo de usos de los servicios web? Abre un ticket de soporte y te ayudamos.

Agregar un comentario

Su dirección de correo no se hará público.