Introduccion al ACL
El sistema ACL controla que puede hacer cada usuario en la plataforma.
Que es ACL
Definicion
ACL = Access Control List (Lista de Control de Acceso)
Es un sistema que:
- Define permisos posibles (ACL Objects)
- Asigna permisos a usuarios (ACL Permissions)
- Verifica acceso en cada accion
- Permite control granular
Por que Usar ACL
Beneficios:
- Control granular por usuario
- Seguridad: solo acceso necesario
- Flexibilidad: permisos personalizados
- Auditoria: saber quien puede que
- Escalabilidad: facil de gestionar
Modelo de Permisos
Sin Grupos (User-Based)
IMPORTANTE: El sistema NO usa grupos de ACL. Los permisos se asignan directamente a usuarios.
NO es asi:
| Grupo: Reclutadores |
|---|
| Permiso: process.read |
| Usuarios: Maria, Pedro, Ana |
ES asi:
| Usuario | Permisos |
|---|---|
| Maria | process.read, process.manage |
| Pedro | process.read |
| Ana | process.read, process.manage |
Cada usuario tiene sus propios permisos.
Roles vs Permisos
| ROL | PERMISOS |
|---|---|
| Define la categoria del usuario | Define acciones especificas |
| admin, user, subuser | process.read, events.manage |
| Un rol determina que permisos PUEDE tener | Permisos se asignan individualmente |
Ejemplo:
- subuser puede tener process.manage
- pero no todos los subusers lo tienen
- depende de si se les asigno
Flujo de Verificacion
Cuando se Verifica
Cada request al API pasa por verificacion:
- Usuario hace request
- Autenticacion - ¿Quien es?
- NO → 401 Unauthorized
- SI → Continua
- Autorizacion (ACL) - ¿Puede hacer esto?
- PERMITIDO → Continua
- DENEGADO → Error 403
Logica de Decision
¿Usuario puede hacer X?
- ¿Es admin?
- SI → Permitido (admins tienen todo)
- ¿Existe ACL Object para X?
- NO → Denegado
- ¿Su rol esta en allowedRoles?
- NO → Denegado
- ¿Tiene ACL Permission asignado?
- NO → Denegado
- SI, allowed=true → Permitido
- SI, allowed=false → Denegado
Resultado final: Permitido o Denegado
Estructura de Datos
ACL Object
Tabla: acl_object
| Campo | Ejemplo |
|---|---|
| id | 1 |
| key | "process.manage" |
| description | "Crear, editar y eliminar procesos" |
| module | "process" |
| allowedRoles | ["admin", "user", "subuser"] |
| createdAt | 2024-01-01 |
| updatedAt | 2024-01-01 |
Campos:
- key: identificador unico (module.action)
- description: explicacion legible
- module: agrupacion logica
- allowedRoles: roles que pueden tener este permiso
ACL Permission
Tabla: acl_permission
| Campo | Ejemplo |
|---|---|
| id | 100 |
| type | "user" |
| allowed | true |
| userId | 456 |
| objectId | 1 |
| createdAt | 2024-01-15 |
| updatedAt | 2024-01-15 |
Campos:
- type: siempre "user" (no hay grupos)
- allowed: true/false
- userId: a quien se asigna
- objectId: que permiso (FK a acl_object)
Convencion de Nombres
Formato de Key
Los permisos siguen el formato: [modulo].[accion]
Ejemplos:
- process.read
- process.manage
- events.read
- events.manage
- users.read
- users.manage
Acciones comunes:
- read: ver/listar
- manage: crear/editar/eliminar
- export: exportar datos
- take: realizar (ej: tomar prueba)
Modulos
Modulos del sistema:
- process - Procesos de reclutamiento
- events - Eventos y calendario
- users - Gestion de usuarios
- projects - Proyectos
- job-positions - Vacantes
- tests - Pruebas y evaluaciones
- user-tests - Asignacion de pruebas
- analytics - Metricas y reportes
- automation - Automatizaciones
- calendar - Calendario
- orders - Ordenes y facturacion
- acl - Gestion de permisos
Cache de Permisos
Redis Cache
Los permisos se cachean en Redis:
Key: acl:permissions:{userId}
TTL: 5 minutos
Contenido:
{
"process.read": true,
"process.manage": true,
"events.read": true,
"events.manage": false
}
Beneficios:
- Consulta rapida (no DB cada vez)
- Reduccion de carga
- Mejor performance
Invalidacion
El cache se invalida cuando:
- Se asigna/quita permiso
- Se cambia rol del usuario
- Usuario cierra sesion
- Expira TTL (5 min)
Permisos por Defecto
Admins
Los admins tienen TODOS los permisos:
admin.hasPermission("cualquier.cosa") = true
No necesitan asignacion explicita.
Users
Users nuevos tienen permisos basicos:
- Ver sus propios datos
- Gestionar sus proyectos
- Crear subusers
- Permisos adicionales segun config
Subusers
Subusers nuevos tienen permisos minimos:
- Ver datos de la empresa
- Demas permisos: deben asignarse
- Depende de configuracion del admin
Ejemplo Completo
Scenario
Maria es subuser de Empresa ABC. Queremos que pueda:
- Ver procesos
- Gestionar eventos
- NO gestionar usuarios
Configuracion:
-
ACL Objects existen:
- process.read (id: 1)
- events.manage (id: 5)
- users.manage (id: 10)
-
ACL Permissions para Maria (id: 456):
- objectId: 1, allowed: true (process.read)
- objectId: 5, allowed: true (events.manage)
- (sin entry para users.manage = denegado)
-
Resultado:
- Maria puede ver procesos
- Maria puede gestionar eventos
- Maria NO puede gestionar usuarios
Permisos
acl.read - Ver permisos asignados
acl.manage - Asignar/quitar permisos
Nota: Solo admins tienen estos permisos por defecto.
Proximos Pasos
- ACL Objects - Ver permisos disponibles
- Asignar Permisos - Dar acceso a usuarios
- Verificar Permisos - Como funciona internamente