Control de acceso basado en roles

El control de acceso basado en roles (RBAC) es un método para asignar permisos a los usuarios en función de sus roles. Considera usar RBAC en los siguientes escenarios:

• Tienes múltiples usuarios con diferentes necesidades de acceso: RBAC es ideal cuando los usuarios necesitan permisos variados basados en roles, como administrador, editor o espectador.
• Necesitas simplificar la gestión de permisos: Es eficiente para gestionar grandes grupos de usuarios asignando roles en lugar de establecer permisos individualmente.
• Tu aplicación sirve a diferentes departamentos o equipos: Es útil en escenarios donde diferentes grupos requieren niveles distintos de acceso a los recursos.

Entender cómo funciona el control de acceso basado en roles

Permisos (Alcances)

Permiso se refiere a la autorización para acceder a un recurso de API. En el mundo real, entidades como pedidos, productos y documentos pueden designarse como recursos, y se pueden asignar diversas acciones.

Ejemplos de permisos, incluyendo la capacidad de editar un pedido, leer un documento y eliminar un producto, son los siguientes:

• write:orders
• read:documents
• delete:products

La figura anterior muestra que el permiso read:item en el recurso https://api-1.store.io es diferente del permiso read:item en el recurso https://api-2.store.io.

Si no se proporciona un recurso de API, el permiso se tratará como "para OIDC". Usualmente, esto no es lo que deseas en RBAC.

Aprende cómo configurar permisos de API en Logto.

Roles

Los roles son una agrupación de permisos que se pueden asignar a los usuarios. También proporcionan una forma de agregar permisos definidos para diferentes APIs, haciendo que agregar, eliminar o ajustar permisos sea más eficiente que asignarlos individualmente a los usuarios.

Aquí tienes un ejemplo de un rol order_admin con varios permisos para dos recursos:

Está bien tener superposición de permisos entre roles.

Aprende cómo configurar roles en Logto.

Ejemplo: Una librería en línea

Supongamos que tienes una librería en línea para gestionar. Aquí, simplificamos mucho el modelo de control de acceso para fines de demostración.

El modelo se divide en dos recursos de API principales: pedidos y productos. Tienen diferentes indicadores de recurso como se muestra a continuación:

• Pedidos: https://api.store.io/orders
• Productos: https://api.store.io/products

Para cada recurso, te gustaría separar los permisos en leer, escribir y eliminar. Así que defines seis permisos en total:

• https://api.store.io/orders
  • Permiso read:order
  • Permiso write:order
  • Permiso delete:order
• https://api.store.io/products
  • Permiso read:product
  • Permiso write:product
  • Permiso delete:product

Aquí está la ilustración de este modelo:

Quieres tener dos tipos de administradores, administrador de pedidos y administrador de productos:

• Administrador de pedidos puede gestionar pedidos y ver productos (ya que los pedidos consisten en productos), pero no puede gestionar productos.
• Administrador de productos puede gestionar productos, y no debería estar al tanto de ningún pedido.

Así que creas dos roles, order_admin y product_admin, con los permisos:

• order_admin
  • https://api.store.io/orders
    • read:order, write:order, delete:order
  • https://api.store.io/products
    • read:product
• product_admin
  • https://api.store.io/products
    • read:product, write:product, delete:product

Aquí está la ilustración de estos dos roles:

Está bien asignar tanto order_admin como product_admin a un usuario, entonces tendrán los seis permisos que acabas de definir.

Nota que el administrador de pedidos comparte el permiso read:product con el administrador de productos, y los permisos finales que un usuario tiene son la unión de todos los permisos de los roles que se le han asignado.