CIAM 102: Autorización y Control de Acceso basado en Roles

Antecedentes#

En el artículo anterior, introdujimos el concepto de autenticación (AuthN) y autorización (AuthZ), junto con algunos términos dolorosos de cabeza: Identidad, Organización, Inquilino, etc.

La Organización y el Inquilino son geniales para agrupar Identidades, pero conducen a una democracia absoluta: todos pueden hacer cualquier cosa en este sistema. Mientras que la utopía aún es un misterio, echemos un vistazo a la gobernanza del acceso: Autorización (AuthZ).

¿Por qué necesitamos autorización?#

Notion es un gran ejemplo. Para cada página que posees, puedes elegir mantenerla privada, accesible solo para ti, o compartirla con amigos, o incluso con el público.

O, para una librería en línea, quieres que todos puedan ver todos los libros, pero que los clientes solo puedan ver sus propios pedidos, y que los vendedores solo puedan gestionar los libros en sus tiendas.

AuthZ y AuthN son componentes esenciales de un modelo de negocio complejo. A menudo van de la mano; AuthZ verifica el acceso de un usuario, mientras que AuthN autentica las identidades. Ambos son necesarios para un sistema seguro.

El modelo básico de autorización#

Aquí está uno de los modelos AuthZ más comunes: Si IDENTIDAD realiza ACCIÓN en RECURSO, entonces ACEPTAR o DENEGAR.

En el ejemplo de Notion, el modelo es PERSONA realiza VER en PAGINA.

Si la página es privada:

• Recibirás ACEPTAR al realizar VER en tu PAGINA.
• Todos los demás deberían recibir DENEGAR al realizar VER en tu PAGINA.

Basado en el consenso, la industria desarrolló varias tecnologías de autorización, como el Control de Acceso basado en Roles (RBAC), el Control de Acceso basado en Atributos (ABAC). Hoy nos centraremos en el modelo RBAC de NIST Nivel 1: RBAC Plano.

Control de Acceso basado en Roles#

Ampliemos el ejemplo de la librería. Digamos que tenemos muchos clientes, pero solo un vendedor:

• Los clientes pueden ver y pedir libros, así como ver sus propios pedidos.
• El vendedor puede ver, crear, y eliminar libros, y gestionar los pedidos de los clientes.

Definir recursos#

En Logto, un recurso (es decir, Recurso de API) generalmente representa un conjunto de entidades o ítems, dado que se requiere usar una URL válida como indicador. Por lo tanto, definimos dos recursos:

• Libros: https://api.bookstore.io/books
• Pedidos: https://api.bookstore.io/orders

Una de las ventajas de hacer cumplir el formato de URL es que puede asignar a una dirección real de su servicio de API, lo que mejora la legibilidad y reconocibilidad al integrarse con otros componentes en el sistema.

Definir permisos#

Ya que introdujimos el concepto de recurso, en Logto, también hacemos cumplir que los permisos deben pertenecer a un recurso, a la inversa, los recursos pueden tener permisos.

Añadamos algunos permisos a los recursos:

• Libros: leer, crear, eliminar
• Pedidos: leer, leer:yo, crear:yo, eliminar

Aunque no hay requisito del nombre de un permiso, tenemos la convención como abajo:

While <acción> es requerido para describir un permiso, :<objetivo> puede ser ignorado para describir un objetivo general, es decir, a todas las entidades o ítems en el recurso. Por ejemplo:

• El permiso leer en el recurso Libros significa la acción de leer libros arbitrarios.
• El permiso crear:yo en el recurso Pedidos significa la acción de crear pedidos que pertenecen al usuario actual.

Definir roles#

En resumen, un rol es un grupo de permisos. Creemos dos roles cliente y vendedor y asignemos permisos a ellos como se muestra a continuación:

Puedes notar que la asignación permiso-rol es relaciones de muchos-a-muchos.

Asignar roles a usuarios#

Al igual que la asignación de roles-permisos, la asignación de usuarios-roles también es una relación de muchos a muchos. Por lo tanto, puedes asignar múltiples roles a un solo usuario, y un solo rol puede ser asignado a múltiples usuarios.

Conectar los puntos#

Aquí hay un diagrama completo de relaciones para el modelo RBAC de Nivel 1 en Logto:

En el modelo RBAC, los permisos siempre son "positivos", lo que significa que el juicio de autorización es simple: si un usuario tiene el permiso, entonces acepta; de lo contrario, rechaza.

Supongamos que Alice tiene el rol de vendedor, Bob y Carol tienen el rol de cliente. Describiremos acciones en lenguaje natural primero, y las transcribiremos al formato estándar de autorización: IDENTIDAD realiza ACCIÓN en RECURSO, finalmente dando la conclusión.

• Alice quiere agregar un nuevo libro para vender:
  • El usuario Alice realiza crear en el recurso Libros (https://api.bookstore.io/books).
  • Como a Alice se le ha asignado el permiso de crear Libros según su rol de vendedor, el resultado es ✅ ACEPTAR.
• Alice quiere ver todos los pedidos para ver si la venta cumple con sus expectativas:
  • El usuario Alice realiza leer en el recurso Pedidos (https://api.bookstore.io/orders).
  • Como a Alice se le ha asignado el permiso de leer los Pedidos según su rol de vendedor, el resultado es ✅ ACEPTAR.
• Bob quiere navegar por la lista de libros para ver si hay algún libro que quiera comprar.
  • El usuario Bob realiza leer en el recurso Libros (https://api.bookstore.io/books).
  • Como a Bob se le ha asignado el permiso de leer los Libros según su rol de cliente, el resultado es ✅ ACEPTAR.
• Bob quiere ver el pedido de Carol.
  • Como es el pedido de otra persona, el permiso leer:yo de Pedidos no funciona aquí.
  • El usuario Bob realiza leer en el recurso Pedidos (https://api.bookstore.io/order).
  • Como Bob no tiene permiso de leer los Pedidos, el resultado es ❌ DENEGAR.

Otros niveles RBAC#

Hay cuatro niveles en el modelo RBAC de NIST:

• RBAC Plano
• RBAC Jerárquico
• RBAC Restringido
• RBAC Simétrico

Ve el documento para detalles si estás interesado.

Logto ahora tiene la implementación del Nivel 1 y avanzará a niveles superiores basado en la retroalimentación de la comunidad. ¡No dudes en hacernos saber si un nivel superior se ajusta a tus necesidades!

En la práctica#

Además de la teoría, aún tenemos trabajos técnicos pesados para completar con el fin de hacer que el modelo funcione como se espera:

• Desarrollo de servidor de autenticación y cliente
• Diseño de base de datos para RBAC
• Validación a través de diferentes servicios
• Cumplimiento de seguridad y estándares abiertos
• Gestión de roles, permisos, recursos y asignación

No entres en pánico. Hemos tomado esto en cuenta y añadimos soporte fuera de la caja para cubrir todo lo anterior. Consulta la 🔐 Receta RBAC para aprender cómo usar RBAC en Logto.

Notas finales#

RBAC es un poderoso modelo de gestión de acceso para la mayoría de los casos, pero no hay una solución única para todos. Todavía tenemos algunas preguntas:

• ¿Necesito niveles altos de RBAC?
• ¿Cómo se compara RBAC con otros modelos de autorización?
• ¿Cómo definir el modelo de autorización entre diferentes Organizaciones?