Aptli

Autorización

La autorización define qué pueden y no pueden hacer los usuarios después de la autenticación. Aptli usa un modelo de autorización flexible de dos capas que combina derechos de administrador permisivos con restricciones de rol restrictivas.

Resumen del Modelo de Autorización

Modelo de Seguridad de Cuatro Capas:

Capa 1: Autenticación
    ↓
 ¿Quién eres? (Contraseña, 2FA, OAuth)
    ↓
Capa 2: Derechos de Administrador (Permisivos)
    ↓
 ¿Qué PUEDES modificar? (usersUpdate, pointsCreate, etc.)
    ↓
Capa 3: Restricciones de Rol (Restrictivas)
    ↓
 ¿Qué NO PUEDES ver? (Filtros de campo: propietario, estado, categoría)
    ↓
Capa 4: Renderizado del Lado del Servidor (SSR)
    ↓
 Aplicación en API (datos no autorizados nunca enviados al cliente)

Seguridad de Cuatro Capas:

  1. Autenticación - Quién eres (cubierto en sección de Autenticación)
  2. Derechos de Administrador - Qué PUEDES modificar (concesiones permisivas)
  3. Restricciones de Rol - Qué NO PUEDES ver (filtros restrictivos)
  4. Aplicación del Lado del Servidor - Los datos realmente no existen para usuarios no autorizados

Este modelo proporciona una flexibilidad tremenda mientras mantiene la seguridad.

Derechos de Administrador (Permisivos)

Los derechos de administrador conceden permiso para modificar información o alterar estado. Sin estos derechos, los usuarios solo pueden ver datos y editar su propio perfil.

Derechos de Administrador Comunes:

  • usersUpdate - Editar perfiles de otros usuarios (nombre, título, división - NO correo/contraseña)
  • usersLogout - Forzar cierre de sesión o bloqueo duro de usuarios
  • usersDelete - Eliminar cuentas de usuario
  • usersCreate - Crear nuevos usuarios o restaurar cuentas
  • pointsCreate, pointsUpdate, pointsDelete - Modificar características de puntos
  • ordersCreate, ordersUpdate, ordersDelete - Gestionar órdenes de trabajo
  • assignmentsCreate - Crear asignaciones de trabajo
  • reportsCreate - Enviar reportes de trabajo
  • transactionsCreate - Crear transacciones de inventario

Derechos Super (Superceden a Todos los Otros):

  • appSettingSchemasModify - Modificar configuraciones a nivel de aplicación (dominios, tiempos de espera, seguridad)
  • adminRightsModify - Conceder derechos de administrador a otros usuarios
  • viewDeleted - Ver registros eliminados (casi universal, parcialmente anulado por restricciones de rol)

Verificando Derechos de Administrador del Usuario:

  1. Navegar a Admin → Usuarios
  2. Abrir perfil de usuario
  3. Sección "Derechos de Administrador" lista todos los permisos concedidos

Restricciones de Rol (Restrictivas)

Página de administración de roles mostrando restricciones de rol configuradas

Los roles son colecciones de restricciones que previenen ver y alterar registros con ciertas características. La membresía en un rol aplica todas las restricciones a ese usuario.

Componentes de Rol:

  • Miembros - Usuarios que tienen estas restricciones aplicadas
  • Propietario - Usuario que controla la membresía (o usuarios con derecho de administrador rolesUpdate)
  • Restricciones de Rol - Filtros a nivel de campo ocultando datos específicos

Estructura de Restricción de Rol

Página de detalle de rol mostrando configuración de restricción a nivel de campo

Cada restricción define:

  • Modelo - Qué tipo de datos (puntos, polígonos, asignaciones, etc.)
  • Campo - Qué propiedad filtrar (propietario, estado, categoría, campos personalizados)
  • Comparación - Cómo coincidir (=, !=, >, <, contiene, etc.)
  • Valor de Filtro - Qué valor coincidir contra
  • Permisos - Qué está bloqueado (leer, editar, crear, eliminar)

Caso de Uso de Ejemplo: Separación de Contratistas

Escenario: Prevenir que Contratista A vea el trabajo de Contratista B

Configuración:

  1. Crear rol: "Contratista A"
  2. Agregar restricción de rol:
    • Modelo: Punto (características)
    • Campo: propietario
    • Comparación: =
    • Valor de Filtro: Contratista B
    • Permisos: Leer ✓, Editar ✓, Crear ✓, Eliminar ✓ (todos verdaderos = no puede hacer ninguno de estos)
  3. Agregar usuarios de Contratista A como miembros

Resultado:

  • Los miembros de Contratista A no pueden ver ningún punto donde propietario = "Contratista B"
  • No solo oculto en UI - API devuelve datos como si los registros no existieran
  • No puede ver accidentalmente vía captura de pantalla, llamada API o exportación
  • Completamente aplicado del lado del servidor

Casos de Uso Adicionales

Por Etapa de Trabajo: Prevenir que trabajadores de campo vean reportes de validación QC:

Rol: "Trabajadores de Campo"
Restricción:
  Modelo: Validación
  Campo: estado
  Comparación: !=
  Valor de Filtro: "" (cualquier valor)
  Permisos: Leer ✓

Los trabajadores de campo no pueden ver validaciones en absoluto.

Por Tipo de Activo: Separar equipos de infraestructura (postes/ductos vs. equipo activo):

Rol: "Equipo Civil"
Restricción:
  Modelo: Punto
  Campo: categoría
  Comparación: =
  Valor de Filtro: "Equipo Activo"
  Permisos: Leer ✓, Editar ✓, Crear ✓, Eliminar ✓

El equipo civil no puede ver o modificar puntos de equipo activo.

Por Físico/Lógico: Separar acceso a datos de oficina (relaciones de capacidad vs. ubicaciones de oficina):

Rol: "Analistas de Capacidad"
Restricción:
  Modelo: Punto
  Campo: capa
  Comparación: =
  Valor de Filtro: "Ubicaciones de Oficina"
  Permisos: Editar ✓, Crear ✓, Eliminar ✓

Los analistas pueden ver oficinas pero no modificar ubicaciones (solo lectura).

Combinando Derechos de Administrador + Restricciones de Rol

Comportamiento Predeterminado: Todos los usuarios pueden ver todo pero no pueden alterar nada (sin derechos de administrador).

Agregando Acceso de Escritura con Restricciones:

Ejemplo: Los trabajadores de campo pueden editar su propio trabajo pero no el de otros

Derechos de Administrador:
  - reportsCreate: true
  - reportsUpdate: true

Restricciones de Rol:
  Modelo: Reporte
  Campo: reportedBy
  Comparación: !=
  Valor de Filtro: [ID de usuario actual]
  Permisos: Editar ✓

Resultado:

  • Los trabajadores pueden crear reportes (derecho de administrador concedido)
  • Los trabajadores pueden editar SOLO sus propios reportes (restricción de rol filtra otros)
  • No pueden ver o modificar reportes de otros trabajadores

Aplicación del Lado del Servidor (SSR)

Cómo Funciona:

  • Todas las consultas API filtradas antes de búsqueda en base de datos
  • Restricciones de rol aplicadas del lado del servidor (no solo ocultando UI)
  • El usuario no puede bypass vía llamadas API directas, herramientas del navegador o exportaciones
  • Los datos realmente no existen para usuarios no autorizados

Consulta de Ejemplo:

Usuario solicita: GET /api/points

Sin restricciones:
  SELECT * FROM points WHERE deletedAt IS NULL

Con restricción de rol (propietario != "Contratista B"):
  SELECT * FROM points 
  WHERE deletedAt IS NULL 
  AND (propietario IS NULL OR propietario != "Contratista B")

Implicaciones de Seguridad:

  • Captura de pantalla de pantalla de alguien más no ayudará (los datos no cargarán para ti)
  • No puede exportar datos restringidos (API aplica filtros)
  • No puede "adivinar" IDs de registro (filtrados antes de búsqueda de ID)
  • Incluso si atacante ve ID de registro en tráfico de red, fetch devuelve 404

Gestionando Roles

Creando Roles:

  1. Navegar a Admin → Roles
  2. Hacer clic en "Crear Rol"
  3. Ingresar nombre de rol y descripción
  4. Agregar miembros (arrastrar usuarios al campo miembros)
  5. Agregar restricciones de rol (puede tener múltiples)
  6. Guardar

Editando Roles:

  • Solo propietario del rol O usuarios con derecho de administrador rolesUpdate
  • Puede agregar/remover miembros
  • Puede modificar restricciones
  • Puede eliminar rol (libera miembros de restricciones)

Membresía de Rol:

  • Los usuarios pueden estar en múltiples roles (restricciones combinadas)
  • Dejando organización: Remover de todos los roles antes de eliminar cuenta
  • Membresía masiva: Arrastrar múltiples usuarios a la vez

Personalizando Autorización para Nuevos Usuarios

Configuración de Configuraciones de App (Requiere appSettingSchemasModify):

  1. Navegar a Configuraciones de App → Autenticación
  2. "Roles para Nuevos Usuarios" - Auto-asignar roles a nuevas cuentas
  3. "Derechos de Administrador para Nuevos Usuarios" - Permisos predeterminados concedidos
  4. Guardar

Configuraciones Típicas:

Predeterminados de Trabajador de Campo:

Roles: ["Trabajadores de Campo"]
Derechos de Administrador: {
  reportsCreate: true,
  assignmentsRead: true
}

Predeterminados de Coordinador de Oficina:

Roles: []
Derechos de Administrador: {
  assignmentsCreate: true,
  ordersCreate: true,
  stockItemsView: true
}

Sin Auto-Concesión (Revisión Manual):

Roles: []
Derechos de Administrador: {} (ninguno)

Los administradores asignan manualmente después de revisión de cuenta.

Viendo Permisos Efectivos

Para Usuario Específico:

  1. Navegar al perfil de usuario
  2. Sección "Derechos de Administrador" - Qué PUEDEN hacer
  3. Sección "Roles" - Qué NO PUEDEN ver (vía restricciones)
  4. Vista combinada muestra permisos efectivos

Probando Permisos:

  1. Iniciar sesión como usuario (o impersonar con permiso de admin)
  2. Navegar normalmente
  3. Datos restringidos simplemente no aparecen
  4. Acciones sin derechos de administrador deshabilitadas/ocultas

Mejores Prácticas

Comenzar Restrictivo, Conceder Según Necesidad:

  • Nuevos usuarios obtienen permisos mínimos
  • Agregar derechos de administrador según roles requieran
  • Más fácil conceder que revocar (evita "crecimiento de permisos")

Usar Roles para Visibilidad de Datos:

  • Separar contratistas (prevenir inteligencia de competencia)
  • Separar etapas de trabajo (QC de trabajadores de campo)
  • Separar tipos de activo (infraestructura de equipo activo)

Usar Derechos de Administrador para Capacidades:

  • Quién puede crear asignaciones
  • Quién puede modificar inventario
  • Quién puede conceder permisos

Documentar Propósito de Rol:

  • Nombre de rol claro ("Contratista A" mejor que "Rol 1")
  • Descripción explica restricciones
  • Ayuda a administradores futuros entender intención

Auditorías Regulares de Permisos:

  • Revisión trimestral de derechos de administrador de usuario
  • Remover derechos no usados (usuario cambió roles)
  • Verificar membresías de rol (usuarios dejaron organización)

Monitorear Intentos de Acceso:

  • Registrar intentos de autorización fallidos
  • Patrón de denegaciones = usuario intentando acceso no autorizado
  • Investigar y ajustar permisos o educar usuario

Principio de Menor Privilegio:

  • Conceder permisos mínimos requeridos para función de trabajo
  • Acceso elevado temporal para proyectos (remover después)
  • Derechos super (adminRightsModify) solo a administradores confiables