Tenant separa organizaciones y datos. Project selecciona pertenencia, esquema y ámbito de ejecución dentro del tenant. El proyecto activo es una decisión de sesión firmada y validada por el servidor, no un filtro estético.
Seguridad y gobernanza
Las decisiones de seguridad permanecen bajo control del servidor y vinculadas al ámbito.
La visibilidad en el navegador no constituye un límite de autorización. Las rutas protegidas, los servicios de aplicación y los predicados de repositorio vuelven a evaluar identidad, tenant, proyecto y permisos cuando la operación lo exige.
Seguridad y gobernanza
Cada solicitud autenticada debe coincidir con un registro JTI activo y vinculado al actor, con estado actual de tenant y usuario, duración definida por política, tiempo límite de inactividad y contexto Project activo. Un fallo de registro, material de firma ausente, revocación o discordancia de identidad falla de forma cerrada, sin volver a un contexto anónimo u obsoleto del navegador.
Se implementan metadatos, login y ACS de SAML para tenant, vinculación o aprovisionamiento JIT de identidad externa, política de dominio y evidencia MFA declarada por el IdP. La generación de endpoints utiliza el origen público controlado por el servidor y la correlación AuthnRequest emplea estado firmado de corta duración vinculado a proveedor y solicitud.
RLS de Analytics está protegido y controlado por el servidor. Un filtro de ejecución del cliente no puede falsificar los metadatos de origen RLS, y las identidades de caché incluyen ámbito de permisos y RLS en lugar de depender solo del texto SQL.
Credenciales, tokens, headers de autorización, claves privadas y material de URL firmada no deben aparecer en metadatos públicos, prompts ni auditoría genérica. Un texto enmascarado no es una credencial ejecutable. Cuando un flujo exige una revelación única, esta queda acotada, cifrada según la configuración, limitada en el tiempo y registrada sin persistir el secreto en evidencia genérica.
Tenant y Project forman el contexto de seguridad activo.
Tenant separa organizaciones y datos. Project selecciona pertenencia, esquema y ámbito de ejecución dentro del tenant. El proyecto activo es una decisión de sesión firmada y validada por el servidor, no un filtro estético.
El registro de sesión conserva la autoridad después del login.
Cada solicitud autenticada debe coincidir con un registro JTI activo y vinculado al actor, con estado actual de tenant y usuario, duración definida por política, tiempo límite de inactividad y contexto Project activo. Un fallo de registro, material de firma ausente, revocación o discordancia de identidad falla de forma cerrada, sin volver a un contexto anónimo u obsoleto del navegador.
Cambiar Project es una acción del servidor protegida por CSRF que vuelve a emitir contexto sin ampliar el token original ni la caducidad de la política.
Logout es un POST protegido por CSRF; cambiar o restablecer contraseña y eliminar la cuenta revocan las sesiones activas.
Las solicitudes JSON reciben un fallo de autenticación estructurado y eliminación de cookies; la navegación del navegador limpia el contexto antes de redirigir.
SAML está disponible con límites explícitos.
Se implementan metadatos, login y ACS de SAML para tenant, vinculación o aprovisionamiento JIT de identidad externa, política de dominio y evidencia MFA declarada por el IdP. La generación de endpoints utiliza el origen público controlado por el servidor y la correlación AuthnRequest emplea estado firmado de corta duración vinculado a proveedor y solicitud.
SAML no crea pertenencia Project; el usuario sigue necesitando acceso autorizado al tenant y al Project.
TOTP y WebAuthn en la aplicación, desafíos de recuperación y una interfaz completa de inventario y revocación de sesiones no son capacidades actuales.
Una política de MFA por contraseña no admitida se rechaza, en lugar de almacenarse como falso control.
RLS y los filtros de ejecución no son intercambiables.
RLS de Analytics está protegido y controlado por el servidor. Un filtro de ejecución del cliente no puede falsificar los metadatos de origen RLS, y las identidades de caché incluyen ámbito de permisos y RLS en lugar de depender solo del texto SQL.
Los secretos permanecen fuera de la evidencia genérica.
Credenciales, tokens, headers de autorización, claves privadas y material de URL firmada no deben aparecer en metadatos públicos, prompts ni auditoría genérica. Un texto enmascarado no es una credencial ejecutable. Cuando un flujo exige una revelación única, esta queda acotada, cifrada según la configuración, limitada en el tiempo y registrada sin persistir el secreto en evidencia genérica.
La solidez actual de IAM se declara con precisión.
Existen contratos de permisos específicos por módulo, pero no está completo un permiso negativo persistente universal ni una combinación DENY-wins en toda la plataforma. No debe insinuarse MFA en la aplicación ni step-up más allá de los controles actuales del proveedor de identidad y de sesión.
Siguiente paso
Empiece por el flujo que no puede permitirse ambigüedades.
Incluya los sistemas, responsables, reglas, obligaciones de entrega y requisitos de evidencia relevantes.
Analizar un flujo crítico