Modelo de autorización ReBAC con OpenFGA: la implementación.

En la primera parte de OpenFGA repasamos conceptos básicos de autenticación, autorización, modelos de autorización y herramientas como Keycloak y OpenFGA. En esta segunda parte veremos un escenario donde se implementa el modelo ReBAC con una aplicación de ejemplo.

Utilizaremos como aplicación de ejemplo un catálogo de una tienda online. Consideremos una tienda online llamada “Best eMarket” con los siguientes elementos:

• Usuarios: empleados/as de la tienda.
• Recursos: productos en el catálogo de la tienda.
• Relaciones: roles específicos y permisos de acceso.

Arquitectura

El diagrama muestra una arquitectura de autenticación y autorización utilizando Keycloak, OpenFGA y la aplicación de ejemplo.

Componentes

1. Usuarios:

• Representados por un icono de ordenador.
• Interactúan con la capa de aplicación.

2. Capa de aplicación:

• Contiene la aplicación web y un servicio de API internos.
• Se comunica con la capa de autorización para la autenticación y autorización de usuarios.

3. Capa de autorización:

• Keycloak: sistema de autenticación. Además, se utiliza como herramienta para definir el modelo de autorización definiendo usuarios y roles.
• EventPublisher: detecta eventos de gestión de identidad en Keycloak y los traduce al modelo de autorización almacenado en OpenFGA.
• OpenFGA: sistema de autorización basado en relaciones. Recibe llamadas desde la API de la aplicación para comprobar la relación entre usuarios y recursos.

Flujo de datos

1. Autenticación con Keycloak:

• Los usuarios inician sesión en la aplicación, y las credenciales son enviadas a Keycloak utilizando el protocolo OpenID Connect (OIDC).
• Keycloak verifica la identidad del usuario y proporciona un token de autenticación.

2. Interacción con la aplicación:

• Una vez autenticados, los usuarios pueden realizar acciones en la aplicación, como ver un producto.
• La aplicación realiza una solicitud a la API correspondiente para obtener los datos del producto, acompañando la llamada con el token de autenticación del usuario.

3. Autorización con OpenFGA:

• Antes de que la API de la aplicación procese la solicitud, verifica si el usuario tiene los permisos necesarios para realizar la acción solicitada.
• La API de autorización envía una solicitud a OpenFGA para comprobar los permisos basados en relaciones.
• OpenFGA utiliza la información de la solicitud para determinar si el usuario tiene los permisos necesarios y responde con la decisión de autorización.

Sistema ReBAC

1. Usuarios:

• Ana (Administradora)
• Bruno (Empleado)
• Carlos (Nuevo empleado)
• Diana (Auditora)

2. Recursos:

• Entradas de productos en el catálogo

3. Relaciones:

• Un usuario puede estar asignado a un rol
• Un rol puede contener otros roles
• Un usuario puede ser parte de un grupo
• Un grupo puede tener uno o varios roles asignados

Modelo de relaciones

1. Relación de rol asignado:

• Los usuarios con el rol admin-catalog pueden ver y editar todos los productos en el catálogo.
• Los usuarios con el rol audit-catalog pueden ver todos los productos del catálogo.
• Un grupo puede asociarse a un rol, heredando así todos los permisos contenidos en el mismo o en otros roles hijos.

2. Relación de grupos:

• Los empleados que se encuentran en el grupo employee heredan los permisos del rol admin-catalog asignado a ese grupo.
• Los usuarios asignados al grupo audit heredan los permisos del rol audit-catalog.

En este escenario, básicamente, se estaría implementando una combinación de RBAC y GBAC, lo que demuestra la flexibilidad de OpenFGA.

Configuración de Keycloak

Una vez desplegado Keycloak, es necesario configurar el cliente, los usuarios, roles y grupos. Creamos el cliente con Client ID: portal según se muestra en las capturas de pantalla:

A continuación se deberán definir los usuarios, grupos y roles como se indica aquí:

Lista de roles y grupos

Una vez definidos todos los usuarios, roles y grupos, en OpenFGA se podrá comprobar las tuplas de relación generadas.

Modelo de autorización

En este ejemplo, se utilizará un modelo de autorización sencillo con el objetivo de cubrir las necesidades de la aplicación.

OpenFGA permite definir los modelos de autorización utilizando su lenguaje de dominio específico (DSL). En la documentación oficial se explican los conceptos del modelo. Básicamente, permite definir cualquier tipo de relación (directas, indirectas o dinámicas) entre objetos y usuarios, lo que permite definir modelos de autorización tan simples o complejos como lo requiera la aplicación.

Definición de tipos y relaciones

El modelo utilizado en este escenario es el siguiente:

model
  schema 1.1
type group
  relations
    define assignee: [user]
type role
  relations
    define assignee: [user] or assignee from parent or assignee from parent_group
    define parent: [role]
    define parent_group: [group]
type user

1. Las primeras dos líneas especifican la versión del esquema de OpenFGA a utilizar.

model
  schema 1.1

2. Las siguientes tres líneas contienen la definición de un tipo grupo y las relaciones que puede tener.

type group
  relations
    define assignee: [user]

Lo que se traduce a que un grupo puede asignar usuarios.

3. Las siguientes cinco líneas definen un “role” y las posibles relaciones que puede tener.

type role
  relations
    define assignee: [user] or assignee from parent or assignee from parent_group
    define parent: [role]
    define parent_group: [group]

La relación asignee indica que un usuario puede tener un rol de manera directa o heredada a través de un rol padre o de un grupo padre.

La relación parent permite definir jerarquías de roles, donde un rol puede tener otro rol como su padre.

La relación parent_group asocia un rol con un grupo, permitiendo que los miembros del grupo hereden los roles asignados al grupo.

4. La última línea define el tipo usuario que representa a los usuarios de la aplicación.

type user

Definición de tuplas de relaciones

Una vez definido el modelo, el siguiente paso sería definir las tuplas de relaciones.

OpenFGA almacena la información de autorización en este formato, debe incluir los siguientes campos:

• Un user. Ejemplo: user:ana
• Una relation. Ejemplos: member, parent_role, editor
• Un object. Ejemplo: file:licence.pdf, repo:paradigma/openfga, domain:example.com
• (Opcionalmente) una condition. Ejemplo: {“condition”: “in_whitelist_ip_range”}

El resultado sería algo como:

{
  user: 'user:ana',
  relation: 'member',
  object: 'document:project_x',
} 

En cualquier implementación de OpenFGA, la carga de tuplas puede suponer un proceso tedioso y propenso a fallos, por lo que se recomienda automatizarlo mediante el uso de la CLI o SDK.

EventPublisher

Este componente, desarrollado como una extensión de Keycloak y utilizando las Service Provider Interfaces (SPI), permite:

• Captar eventos como puede ser la creación de un usuario o la asignación de roles o grupos.
• Traducir este evento a una tupla de relación de OpenFGA.
• Publicar el evento a modo de actualización de tupla de relación en el servidor de OpenFGA.

De este modo conseguimos tener una integración completa entre Keycloak, que se encarga de gestionar la autenticación de usuarios y donde definiremos usuarios, grupos y roles, y OpenFGA, que se encargará de almacenar el modelo de autorización y comprobar en todo momento la relación entre usuarios y objetos en la aplicación.

Una vez instalado, es necesario activarlo en la configuración del Realm, en la lista de Events Listener.

Integración con la aplicación en desarrollo

En la documentación oficial de OpenFGA se encuentran ejemplos de integración con aplicaciones en Node.js (framework Fastlify) y Go (framework Fiber).

Los pasos necesarios para integrar una aplicación con OpenFGA serían:

1. Instalación y configuración de una librería que permita gestionar tokens JWT.
2. Definir una función encargada de la autenticación y obtener el identificador del usuario una vez autenticado.
3. Definir función encargada de comprobar la autorización contra OpenFGA.
4. Utilizar el identificador de usuario para comprobar que el mismo cuenta una relación al rol requerido para ejecutar la operación (lectura, escritura, borrado, etc).
5. Integrar la función de autorización para que se ejecute antes de cada operación que requiera acceso a un recurso protegido.

Comprobaciones en OpenFGA

En el playground de OpenFGA se podrá observar el modelo de autorización, las relaciones posibles en forma de gráfico y las tuplas creadas para esta versión del modelo.

Además, se podrán realizar consultas de prueba para comprobar los permisos efectivos que se aplican a cada usuario. Esto se logra en el apartado de Tuple Queries, el playground otorga facilidades como sugerencias y autocompletado.

Según el modelo que hemos definido, la lista de permisos efectivos sería la siguiente:

Una vez definido el modelo de autorización en OpenFGA, creados los usuarios, grupos y roles en Keycloak y comprobado que las tuplas de relación se han generado correctamente en OpenFGA, se cumplen las condiciones necesarias para que la aplicación realice consultas de autorización.

Demostración

Al acceder a la aplicación, el usuario es recibido por la página de inicio con el botón de Log in.

Al iniciar el proceso de autenticación, es redirigido al portal de Keycloak donde debe introducir sus credenciales.

Una vez autenticado, es redirigido de vuelta a la aplicación. En este punto se comprueban los permisos del usuario.

En el caso de Carlos, al ser un empleado nuevo, aún no cuenta con permisos de acceso, por lo que vería la siguiente página.

Sin embargo, alguien como Diana, que se encuentra en el grupo audit-group, de forma heredada, cuenta con el rol audit-catalog que, a su vez, es padre del rol view-product, por lo que podrá ver la lista de productos.

Sin embargo, Diana no cuenta con el rol edit-product, por lo que no podrá publicar nuevos productos.

Pero Ana, que cuenta con el rol admin-catalog y que tiene como roles hijos a view-product y edit-product, podrá publicar los nuevos productos.

Conclusiones

Como se ha podido observar en este ejercicio, OpenFGA es una solución robusta y flexible que permite implementar modelos de control de acceso avanzados. Su capacidad para manejar relaciones complejas y definir políticas detalladas lo hace adecuado para entornos empresariales que requieren una gestión precisa de permisos de acceso.

Como ventajas, se pueden identificar:

• Flexibilidad: permite definir políticas de acceso complejas y adaptables a cualquier necesidad de negocio.
• Escalabilidad: se ha diseñado de forma que soporta eficientemente grandes volúmenes de relaciones y políticas.
• Facilidad de adopción: permite contar con distintas versiones del mismo modelo, lo que permite trabajar en entornos productivos y de desarrollo al mismo tiempo.
• Seguridad: proporciona un control granular y preciso sobre los permisos de acceso, mejorando la seguridad de los recursos.

Sin embargo, su implementación en un entorno productivo hoy en día cuenta con algunos desafíos como pueden ser

• Configuración inicial: la configuración inicial y definición del modelo de autorización puede ser complejo y requiere de un conocimiento profundo de las necesidades de negocio y las posibilidades de OpenFGA.
• Integración con desarrollo: OpenFGA ofrece una lista de SDKs en distintos lenguajes de programación, pero la implementación recae sobre el equipo de desarrollo y requiere de cierto nivel de conocimientos sobre el funcionamiento de OpenFGA.
• Mantenimiento: a medida que las necesidades del negocio cambian, es necesario mantener al día las políticas y relaciones.
• Gestión del cambio: en entornos dinámicos, la gestión del modelo puede ser compleja y requerir herramientas adicionales para su manejo.
• Compatibilidad con sistemas legacy: la integración de OpenFGA en sistemas heredados o aplicaciones personalizadas puede requerir adaptaciones y pruebas exhaustivas.

La implementación de OpenFGA en un entorno productivo puede ofrecer numerosos beneficios en términos de flexibilidad, escalabilidad y seguridad en la gestión de permisos de acceso. Sin embargo, también presenta una serie de desafíos que deben ser valorados antes de tomar la decisión de hacerlo.