Cuatro motores de autorización comparados en un benchmark en vivo

Un desarrollador ha montado un benchmark interactivo para comparar cuatro motores de control de acceso: Cedar, Rego (OPA), Casbin y una reimplementación del algoritmo de Zanzibar. En lugar de limitarse a una tabla estática de características, el autor ha ejecutado las mismas reglas en los cuatro sistemas y ha recorrido todas las combinaciones posibles de solicitudes para ver dónde fallan cada uno.

El proyecto, disponible en GitHub, funciona sin backend. Utiliza las bindings de WebAssembly de Cedar, la build de TypeScript de Casbin y una implementación propia de Zanzibar de unas cien líneas. Rego se ejecuta compilando OPA a JavaScript/WASM, lo que permite evaluar políticas en tiempo real con un peso de 8 MB y un tiempo de respuesta de unos 2 milisegundos tras la carga inicial.

Dónde se separan los motores

La diferencia más reveladora aparece cuando se añade la restricción de "horario de trabajo". Los tres motores basados en políticas (Cedar, Rego y Casbin) la manejan sin problema, pero el modelo ReBAC (basado en relaciones, como Zanzibar y OpenFGA) se queda corto. La función de verificación check(user, relation, object) tiene tres argumentos y ninguno de ellos puede contener un reloj. Como resultado, mientras los otros tres deniegan la edición a las 3 de la mañana, el motor ReBAC la permite.

Esta brecha explica por qué OpenFGA introdujo posteriormente las "Conditions", citando explícitamente la hora del día como un caso que las relaciones puras no manejan bien.

Otra diferencia operativa es la gestión de nuevos recursos. Al añadir un documento, Casbin requiere regenerar su tabla de políticas, mientras que en los sistemas ReBAC solo se añade una tupla y el modelo no se ve afectado, lo que simplifica la escalabilidad en ciertos escenarios.

Errores en el propio benchmark

El autor documenta dos fallos críticos que su propio harness de pruebas detectó. Primero, asignó por defecto la regla "editor puede leer" a los usuarios owner, una suposición no presente en los requisitos que dobló las discrepancias de forma injusta. Segundo, el muestreo de horas solo evaluaba puntos interiores (03:00, 10:00, 14:00, 22:00), omitiendo los bordes horarios. Cuando cambió la ventana de un motor a 08:00-19:00, todos los tests pasaron, pero la comparación seguía siendo ciega ante el límite real.

Un detalle de seguridad notable: al desplegar Rego con el set de builtins por defecto, quedó expuesta la función http.send. Esto permitió a un visitante del navegador ejecutar peticiones HTTP y bloquear el runtime de Go del lado del servidor durante toda la sesión, algo que se solucionó restringiendo los builtins disponibles.

Para los arquitectos de seguridad, el valor no está solo en las decisiones, sino en ver las reglas lado a lado. La demo permite arrastrar un slider de horas y observar en tiempo real cómo cada motor interpreta el mismo requisito, algo difícil de captar con documentación teórica.