El modelo de autorización
01La identidad no decide los derechos #sec_877062d8
El proveedor de identidad — Entra ID, Okta, Google, ADFS u otro IdP — responde a una pregunta: ¿quién se acaba de autenticar y con qué nivel de confianza? REVIEWIT responde a las siguientes preguntas: ¿qué puede hacer esta persona, en qué perímetro y hasta cuándo?
Esta separación evita que un administrador de directorio cliente pueda atribuirse a sí mismo un rol interno en la plataforma. Los grupos o roles enviados por un IdP no se convierten automáticamente en autorizaciones REVIEWIT. Pueden contribuir a la identificación, pero la decisión de acceso se mantiene, administra, audita y revoca en REVIEWIT.
El identificador pivote es estable e independiente de la dirección de correo o del nombre mostrado. Un cambio de IdP, nombre u organización no debe ni recrear los derechos ni hacer ilegible el historial.
02Tres alcances cerrados #sec_5953283d
El modelo distingue tres niveles que nunca se confunden.
La plataforma. El rol de Operador de Plataforma está reservado al editor. Permite explotar el servicio, sin dar derecho en los datos de un cliente más allá de las operaciones explícitamente previstas.
La suscripción. El Administrador de Suscripción gobierna una suscripción identificada por su identificador público: parámetros comunes, workspaces, roles y capacidades suscritas. Su poder no se extiende a otras suscripciones.
El workspace. Los roles de Gestor, Lector, Lector de Informes y Auditor se ejercen sobre un workspace específico. Se resuelven desde la base en el momento en que la aplicación los necesita, de manera que reflejen una revocación o una expiración sin transportar todos los derechos en una sesión larga.
Esta taxonomía está cerrada por construcción. Añadir un rol de plataforma o suscripción no es una simple operación de configuración: es una decisión de modelo que debe definir su alcance, su administración y su impacto de auditoría.
Ningún rol de administración confiere el derecho de tomar una decisión de revisión. El rol de Gestor de Revisión y las asignaciones de campaña responden a un modelo de negocio distinto. Administrar el contenedor no significa decidir en lugar del revisor.
03El contexto se resuelve en el lado del servidor #sec_f2e08188
Una solicitud del cliente no puede imponer su propia suscripción o su propio workspace. La aplicación resuelve el contexto autorizado en el lado del servidor, a partir de la identidad y las membresías activas. Un identificador proporcionado en una URL o un formulario sigue siendo un objetivo solicitado, nunca una prueba de autorización.
Los derechos están versionados. Cuando un rol es asignado, suspendido, revocado o expirado, una versión de autorización evoluciona. Las sesiones y aplicaciones pueden entonces detectar que su información ya no es corriente y reevaluar los derechos efectivos.
Cada membresía posee un estado, una fecha de otorgamiento, un autor, un motivo y una expiración. Una suspensión temporal se distingue de una revocación definitiva. El modelo hace por tanto visibles tanto el derecho corriente como su ciclo de vida.
La gestión del « último administrador » aplica una protección de fallo cerrado: una suscripción no puede quedarse sin responsable activo debido a una eliminación concurrente o a una expiración mal preparada. La regla se refiere a los derechos realmente efectivos, no sólo al número de líneas presentes.
04Bootstrap, elevación y acceso de emergencia #sec_b168e1cb
El primer administrador de una suscripción debe ser establecido por un procedimiento explícito y rastreable. Este bootstrap no es un atajo permanente: una vez que se instala la gobernanza, los administradores se gestionan según las mismas reglas que las otras membresías.
Las operaciones sensibles pueden requerir una elevación TrustGate, es decir, una autenticación reciente o más fuerte. La elevación confirma la identidad del actor en el momento crítico; no le inventa ningún rol. La autorización se evalúa antes y después de la elevación.
El break-glass es una postura de explotación excepcional, no un rol de cliente oculto. Está limitado en el tiempo, motivado, supervisado y auditado. Nunca se utiliza para eludir silenciosamente el modelo de autorización de una suscripción.
05Una revocación que se propaga y se demuestra #sec_812968cd
Cada atribución, suspensión, expiración y revocación produce un acto en el Audit Trail con su actor, su motivo y su perímetro. Una modificación de los derechos no es solo un cambio de configuración: es un evento de seguridad.
La propagación combina varios mecanismos: versión de roles, lectura de membresías efectivas y resolución en base de los derechos de workspace. El objetivo no es confiar en una cookie hasta su expiración, sino reducir la ventana durante la cual una sesión podría continuar llevando una información que se ha vuelto falsa.
La aproximación periódica verifica finalmente la integridad: los derechos declarados, las sesiones emitidas y las cuentas activas deben contar la misma situación. Una divergencia se convierte en un incidente visible en lugar de una permiso implícito.
06En resumen #sec_e0f5ace1
El modelo de autorización REVIEWIT se basa en una regla fácil de recordar: el IdP prueba la identidad; REVIEWIT posee los derechos. Tres alcances cerrados, un contexto resuelto en el servidor, roles versionados y una trazabilidad sistemática impiden que los privilegios viajen más lejos o durante más tiempo de lo previsto.