Saltar a contenido

Permisos

Descripción

Los permisos definen qué acciones pueden realizarse sobre los recursos de la organización. Son una entidad única en todo el sistema: todos los roles comparten el mismo catálogo de permisos. Los roles se relacionan con permisos de forma muchos a muchos (un rol puede tener cero o más permisos; varios roles pueden compartir los mismos permisos). Ver 03-roles.md.

Estructura: recurso + acción

Cada permiso combina un recurso (entidad) y una acción sobre ese recurso. A nivel de modelo están separados (ENTITY | ACTION).

Recursos actuales:

Recurso Descripción
USER Usuarios de la organización
ROLE Roles de la organización
ORGANIZATION Organizaciones (solo SUPER_ADMIN)

Otros recursos (p. ej. cursos, equipos) se añadirán según el desarrollo del sistema.

Acciones típicas:

Acción Descripción
READ Consultar/listar el recurso
WRITE Crear, actualizar o eliminar (implica implícitamente READ)
COMPLETE Acción explícita específica del recurso (ejemplo)

Se pueden definir acciones custom muy explícitas para recursos concretos según necesidades de negocio.

Implicación: Si un rol tiene WRITE sobre un recurso, tiene implícitamente READ sobre ese mismo recurso.

⚠️ Estado de implementación: la implicación WRITE→READ no está aplicada. El control de permisos exige la coincidencia exacta del permiso requerido; un rol con WRITE pero sin READ explícito sobre el mismo recurso sería rechazado en las rutas que exigen READ. Pendiente de resolución.

Lista cerrada

Los permisos son una lista cerrada: no se crean ni editan en runtime. Se definen durante el desarrollo y se añaden a la base de datos mediante migraciones.

Al añadir un nuevo permiso, se asigna automáticamente al rol administrador de cada organización (salvo la restricción de ORGANIZATION, ver abajo).

Permiso ORGANIZATION (solo SUPER_ADMIN)

El permiso sobre el recurso ORGANIZATION y sus acciones solo puede ser asignado a roles de organizaciones SUPER_ADMIN.

  • Los roles (incluido el administrador) de una organización COMMON no pueden tener permisos sobre ORGANIZATION.
  • Solo los roles de una organización SUPER_ADMIN pueden tener permisos sobre ORGANIZATION (READ, WRITE, etc.).

⚠️ Estado de implementación: la implementación actual no aplica este filtro. Al crear una organización y al registrar (que generan el rol administrador), se asignan todos los permisos del catálogo sin excluir ORGANIZATION según el tipo de organización. En consecuencia, el rol administrador de una organización COMMON termina con permisos sobre ORGANIZATION. Posible brecha de seguridad: debe corregirse en el código para excluir ORGANIZATION en organizaciones COMMON. Pendiente de resolución.

Condiciones de negocio (resumen)

  • Un rol puede tener cero o más permisos.
  • Relación muchos a muchos entre roles y permisos.
  • WRITE implica READ sobre el mismo recurso.
  • Permisos definidos en migraciones; no se crean ni editan en runtime.
  • Nuevos permisos se asignan automáticamente al rol administrador (respetando la regla de ORGANIZATION).
  • Solo organizaciones SUPER_ADMIN pueden tener el permiso ORGANIZATION.