Understanding How Casbin Matching Works in Detail

En este post, explicaré el diseño y la implementación de RBAC utilizando la biblioteca Casbin. Para una plataforma SaaS que maneja múltiples jerarquías de recursos y roles que heredan permisos de niveles superiores, Casbin ofrece una alternativa de alto rendimiento a considerar.

Introducción a RBAC

RBAC es un método para restringir el acceso a recursos basado en los roles que las personas tienen. Para entender mejor cómo funciona el RBAC jerárquico, echemos un vistazo al sistema RBAC de Azure en la siguiente sección y luego intentemos implementar un sistema similar.

Entendiendo el RBAC Jerárquico de Azure

Hay un rol llamado Owner para todos los recursos en Azure. Supongamos que tengo el rol de Owner asignado a mi nivel de suscripción, eso significa que soy el Owner de todos los grupos de recursos y recursos bajo esa suscripción. Si tengo Owner a nivel de grupo de recursos, entonces soy el Owner de todos los recursos bajo ese grupo de recursos.

Esta imagen muestra que tengo acceso de Owner a nivel de suscripción.

Cuando reviso el IAM de un Grupo de Recursos bajo esta Suscripción, puedes ver que he heredado el acceso de Owner de la suscripción.

Así es como el RBAC de Azure es jerárquico. La mayoría del software empresarial utiliza RBAC jerárquico debido a la naturaleza jerárquica de los niveles de recursos. En este tutorial, intentaremos implementar un sistema similar utilizando Casbin.

¿Cómo Funciona Casbin?

Antes de sumergirnos en la implementación, es importante entender qué es Casbin y cómo funciona a un alto nivel. Este entendimiento es necesario porque cada sistema de Control de Acceso Basado en Roles (RBAC) puede variar según requisitos específicos. Al comprender el funcionamiento de Casbin, podemos ajustar el modelo de manera efectiva.

¿Qué es ACL?

ACL significa Lista de Control de Acceso. Es un método en el que los usuarios se mapean a acciones y las acciones a recursos.

La definición del modelo

Consideremos un ejemplo simple de un modelo ACL.

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

1. La request_definition es la plantilla de consulta del sistema. Por ejemplo, una solicitud alice, write, data1 puede interpretarse como "¿Puede el sujeto Alice realizar la acción 'write' en el objeto 'data1'?".

2. La policy_definition es la plantilla de asignación del sistema. Por ejemplo, al crear una política alice, write, data1, estás asignando permiso al sujeto Alice para realizar la acción 'write' en el objeto 'data1'.

3. El policy_effect define el efecto de la política.

4. En la sección matchers, la solicitud se compara con la política utilizando las condiciones r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Ahora probemos el modelo en el editor de Casbin

Abre el editor y pega el modelo anterior en el editor de Modelos.

Pega lo siguiente en el editor de Políticas:

p, alice, read, data1
p, bob, write, data2

y lo siguiente en el editor de Solicitudes:

alice, read, data1

El resultado será:

true

Representación visual del modelo ACL, política y coincidencia de solicitudes

¿Qué es RBAC?

RBAC significa Control de Acceso Basado en Roles. En RBAC, a un usuario se le asigna un rol para un recurso, y un rol puede contener acciones arbitrarias. La solicitud luego verifica si el usuario tiene permiso para realizar la acción en el recurso.

La definición del modelo

Consideremos un ejemplo simple de modelo RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj

1. La role_definition es un constructor de relaciones de gráficos que utiliza un Grafo para comparar el objeto de solicitud con el objeto de política.

Ahora probemos el modelo en el editor de Casbin

Abre el editor y pega el modelo anterior en el editor de Modelos.

Pega lo siguiente en el editor de Políticas:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

y lo siguiente en el editor de solicitudes:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

El resultado será:

true
false
true
true
false

Representación visual del modelo RBAC, la política y la coincidencia de solicitudes

La tabla g - Mapeo de rol a acción tiene un mapeo gráfico del rol a la acción. Este gráfico puede codificarse como una lista de aristas, como se muestra en la política, que es una forma común de representar un gráfico:

g, reader, read
g, owner, read
g, owner, write

información

p indica una política normal que se puede comparar usando el operador ==. g es una función de comparación basada en gráficos. Puede definir múltiples comparadores de gráficos agregando un sufijo numérico como g, g2, g3, ... y así sucesivamente.

¿Qué es RBAC jerárquico?

En RBAC jerárquico, hay más de un tipo de recursos y existe una relación de herencia entre los tipos de recursos. Por ejemplo, "suscripción" es un tipo y "grupoDeRecursos" es otro tipo. Una sub1 de tipo Suscripción puede contener múltiples gruposDeRecursos (rg1, rg2) de tipo GrupoDeRecursos.

Similar a la jerarquía de recursos, habrá dos tipos de roles y acciones: roles y acciones de Suscripción, y roles y acciones de GrupoDeRecursos. Existe una relación arbitraria entre el rol de Suscripción y el rol de GrupoDeRecursos. Por ejemplo, considere un Rol de Suscripción propietario-sub. Este rol es heredado por un Rol de GrupoDeRecursos propietario-rg, lo que significa que si me asignan el rol propietario-sub en la Suscripción sub1, entonces automáticamente también obtengo el rol propietario-rg en rg1 y rg2.

La definición del modelo

Tomemos un ejemplo simple del modelo RBAC jerárquico:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)

1. La definición_de_rol es un constructor de relación gráfica que utiliza un gráfico para comparar el objeto de solicitud con el objeto de política.

Ahora probemos el modelo en el editor de Casbin

Abra el editor y pegue el modelo anterior en el editor de modelos.

Pegue lo siguiente en el editor de políticas:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Y pegue lo siguiente en el editor de solicitudes:

alice, rg-read, rg1

El resultado será:

true

Representación visual del modelo RBAC, la política y la coincidencia de solicitudes

La tabla g - Mapeo de rol a (Acción, Rol) tiene un gráfico que mapea el rol a la acción, mapeo de roles. Este gráfico puede codificarse como una lista de aristas, como se muestra en la política, que es una forma común de representar un gráfico:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

La tabla g2 - Mapeo de Sub a RG tiene un gráfico que mapea la suscripción a grupoDeRecursos:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Representación visual de la coincidencia de sujetos

Representación visual de la coincidencia de acciones

Representación visual de la coincidencia de objetos

información

Cuando se envía una solicitud a Casbin, esta coincidencia ocurre para todas las políticas. Si al menos una política coincide, entonces el resultado de la solicitud es verdadero. Si ninguna política coincide con la solicitud, entonces el resultado es falso.

Conclusión

En este tutorial, aprendimos cómo funcionan los diferentes modelos de autorización y cómo pueden modelarse usando Casbin. En la segunda parte de este tutorial, implementaremos esto en una aplicación de demostración de Spring Boot y aseguraremos las API usando Casbin.