Modelo de autorización
Cómo se combinan clases de identidad, plantillas, capacidades y overrides.
La plataforma separa deliberadamente quién eres (clase de identidad) de qué puedes hacer (capacidades otorgadas por plantillas y excepciones).
Capas del modelo
flowchart TB
subgraph identity [Identidad]
AR[appRole: student / teacher / staff]
end
subgraph org [Organización]
RT[Plantilla de rol]
SC[Alcance: sede / jornada / escuela]
end
subgraph authz [Autorización]
CAP[Capacidades efectivas]
OVR[Overrides grant/deny]
FF[Banderas de función]
end
AR --> RT
RT --> CAP
OVR --> CAP
FF --> CAP
SC --> CAPReglas de evaluación
- La lista efectiva parte de las capacidades de la plantilla asignada.
- Los overrides de concesión añaden capacidades; los de denegación las quitan (prevalecen sobre la plantilla).
- Cada capacidad declara para qué
appRoleaplica; si no coincide con la identidad activa, no se concede. - Algunas capacidades dependen de banderas institucionales (p. ej. roles personalizados).
- La navegación y las rutas del shell consultan el mismo conjunto efectivo — no hay atajos solo en frontend.
No existe un mapa implícito “si eres rector entonces puedes publicar boletines”. Todo pasa por capacidades explícitas en plantilla o override.
Defaults vs. configuración del colegio
Los diagramas y tablas de esta documentación describen el modelo del producto y los valores por defecto que se siembran al crear una escuela. Cada institución puede personalizar plantillas y overrides; el permiso efectivo de un usuario puede diferir de los ejemplos aquí mostrados.
Dónde administrarlo
| Tarea | Ubicación en la app |
|---|---|
| Ver y editar plantillas | Ajustes → Autorización → Plantillas |
| Excepciones por usuario | Ajustes → Autorización → Permisos efectivos |
| Asignar plantilla a persona | Personas → perfil → asignaciones |
| Banderas avanzadas | Ajustes → Autorización (requiere capacidad system.manage_feature_flags) |
Lecturas relacionadas
Impersonación institucional (personal)
La capacidad users.impersonate permite a un actor abrir una sesión temporal como otra persona del personal o docencia. El alcance de a quién se puede impersonar depende de la plantilla del actor, no solo de tener la capacidad activa.
Pirámide de alcance (reglas de producto)
| Plantilla del actor | Puede impersonar | No puede impersonar |
|---|---|---|
| Rector | Todo el personal y docentes | A sí mismo; a otro rector |
| Jefe de sistemas | Personal y docentes salvo rector | Al rector; a sí mismo |
| Coordinador académico / convivencia | Personal y docentes por debajo de su nivel | Al rector, al jefe de sistemas; a sí mismo |
Reglas bloqueadas (no personalizables)
- El rector puede impersonar a todos los perfiles impersonables de la escuela. - Nadie puede impersonar al rector, sin excepción. - Estas dos reglas no se pueden relajar desde Ajustes → Autorización.
Capacidad por defecto y personalización
Al crear una escuela, estas plantillas reciben users.impersonate por defecto:
- Rector y jefe de sistemas (siempre activa, no se puede quitar en la UI).
- Coordinador académico y coordinador de convivencia (activa por defecto; el colegio puede retirarla si tiene
system.manage_role_templates).
Otras plantillas pueden recibir la capacidad de forma explícita en la consola de autorización; el alcance efectivo sigue la pirámide según la plantilla del actor (plantillas sin nivel superior usan el mismo techo que los coordinadores).
Toda sesión de impersonación queda en authorizationAuditLogs y expira automáticamente tras una hora.