OpenFGA en expedientes: permisos con prueba y salida
Guía para usar OpenFGA en permisos finos: modelo, relaciones, chequeo, auditoría, costo inicial y prueba de salida para expedientes sin roles genéricos.
¿Quién puede leer un expediente cuando una matrícula cambia de estado y un comité conserva acceso histórico? OpenFGA v1.20.0 propone separar la decisión de permiso del código de la aplicación. Para colegios profesionales, cámaras y pymes con documentos sensibles, el valor está en guardar relaciones verificables: usuario, rol, expediente, organización y acción permitida. Esta guía muestra qué dato vive en cada componente y cómo probar la salida.
Dónde aparece el permiso que la tabla de roles no alcanza
El permiso fino aparece cuando el mismo usuario necesita leer un expediente, comentar otro y quedar bloqueado para borrar adjuntos. Una tabla simple de roles suele mezclar esas decisiones en columnas generales. OpenFGA trabaja con un modelo de autorización y tuplas de relación: una persona tiene una relación concreta con un objeto concreto, y la aplicación pregunta si esa relación permite una acción. La versión v1.20.0 de OpenFGA fue publicada el 8 de septiembre de 2026. La documentación de conceptos de OpenFGA describe tipos, objetos, usuarios, relaciones, modelos, stores y consultas de chequeo. El dato que corrige la costumbre aparece en esa separación: la aplicación deja de decidir sola y consulta un servicio especializado antes de mostrar, editar o borrar. Para una secretaria administrativa de un colegio profesional con 1.800 matriculados en Cuyo, el objeto visible es un sello de mesa de entradas apoyado sobre expedientes impresos. El antagonista es el rol "admin" usado para todo. Cuando ese rol cruza actas, sanciones y cuotas, nadie sabe si el acceso fue necesario o cómodo.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, la aplicación mantiene usuarios, expedientes y estados en PostgreSQL. Segundo, el equipo define en OpenFGA un modelo con tipos como organización, expediente, comité y usuario. Tercero, cada alta o cambio escribe tuplas de relación: usuario Ana tiene relación redactora con expediente 123, o comité Ética tiene relación revisor con carpeta 45. Cuarto, antes de abrir una pantalla, la aplicación envía una consulta Check a OpenFGA. Quinto, OpenFGA responde permitido o denegado según modelo y relaciones guardadas. Sexto, la aplicación registra la decisión y conserva un log para auditoría. PostgreSQL guarda datos de negocio: expedientes, estados, matrículas y fechas. OpenFGA guarda relaciones de autorización y entrega respuestas de permiso. La aplicación administra el flujo visible y decide qué pantalla mostrar. El backup copia base de negocio, base de OpenFGA y configuración del modelo; la prueba restaura un expediente y verifica que la misma usuaria conserva solo los permisos esperados. El diseño se apoya en ideas publicadas por Google en el trabajo Zanzibar, que describe una autorización global basada en relaciones entre usuarios y objetos. La adopción local toma esa idea y la baja a un control revisable: lo que antes era un if escondido en una vista pasa a un modelo que otra persona puede leer.
Qué se instala o configura primero
Un piloto sobrio usa OpenFGA con Docker, PostgreSQL para la aplicación, una base separada para OpenFGA, proxy interno, métricas básicas y backup diario. Con dólar oficial venta de ARS 1535, una primera implementación puede costar entre USD 750 y USD 1.600, es decir entre ARS 1.151.250 y ARS 2.456.000. Incluye taller de permisos, modelo inicial, diez casos de prueba, integración con una pantalla y restauración ensayada. No incluye reescribir toda la aplicación ni limpiar datos históricos mal cargados. UMSA puede tomar el primer alcance sobre una sola familia documental: expedientes disciplinarios, legajos de socios o actas de comisión. El entregable inicial es una tabla de relaciones esperadas y una prueba automática por cada rol operativo. Si Ana puede comentar y no borrar, la prueba debe decirlo antes de producción. La guía de modelado inicial recomienda empezar por los objetos y las relaciones reales, no por nombres de cargos heredados. Ese orden obliga a conversar con gerencia y mesa de ayuda: quién lee, quién edita, quién aprueba, quién revoca y qué pasa cuando una matrícula cambia.
Dónde se rompe y cómo probarlo
El primer riesgo es copiar la estructura de cargos y llamarla modelo. La señal aparece cuando "admin", "operador" y "consulta" vuelven a cubrir todos los casos. La prueba toma cinco expedientes con estados distintos y verifica acciones por persona, no solo por rol. El segundo riesgo es dejar permisos muertos. La señal aparece cuando una persona cambia de comité y mantiene relaciones viejas. La prueba baja a un usuario de un grupo, consulta los expedientes afectados y exige denegación inmediata o vencimiento documentado. El tercer riesgo es restaurar el sistema con datos y sin modelo. La señal aparece cuando la aplicación abre y todas las consultas de permiso fallan o permiten de más. La prueba recupera aplicación y OpenFGA en un entorno aislado, ejecuta diez consultas Check y conserva el reporte. OpenFGA ayuda cuando la organización acepta escribir sus reglas. La pregunta final no es elegante: ¿cuántos accesos actuales se pueden explicar con una frase y una prueba?
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.