Dominar RBAC en Logto: Un Ejemplo Integral del Mundo Real

Introducción#

El control de acceso y la seguridad son aspectos esenciales de las aplicaciones modernas, asegurando que los usuarios tengan acceso apropiado a los recursos. El Control de Acceso Basado en Roles (RBAC) de Logto ofrece a los desarrolladores una manera eficiente de gestionar el control de acceso y la seguridad en sus aplicaciones. En este artículo, exploraremos las poderosas características de la implementación de RBAC de Logto utilizando un ejemplo del mundo real, ayudándote a entender y aplicar estos conceptos a tus proyectos.

Al examinar fragmentos de código de frontend y backend, obtendrás una perspectiva integral de la integración del RBAC de Logto en tu stack de aplicación. Al final de este artículo, estarás bien equipado para utilizar las características de RBAC de Logto para mejorar la seguridad y el control de acceso de tu proyecto.

Presentando BookHarber: Un caso de uso de librería en línea#

Para demostrar efectivamente las características de RBAC de Logto, utilizaremos un ejemplo del mundo real: BookHarber, una librería en línea. BookHarber ofrece una amplia gama de características para los clientes y el personal, asegurando una experiencia de compra sin problemas y segura.

Las características clave de BookHarber incluyen:

1. Navegación y Compra de Libros: Los usuarios pueden buscar y comprar libros fácilmente de una colección diversa, abarcando varios géneros y autores.
2. Gestión de Pedidos y Seguimiento de Logística: Los clientes registrados pueden gestionar sus pedidos, seguir los envíos y recibir actualizaciones de sus compras.
3. Ofertas Especiales y Actividades de Vacaciones: BookHarber proporciona descuentos exclusivos y promociones durante eventos especiales y días festivos para atraer y recompensar a su base de clientes.
4. Atención al Cliente: Los clientes pueden abrir tickets de soporte para resolver cualquier problema o inquietud que puedan encontrar, recibiendo asistencia rápida del personal de BookHarber.
5. Gestión de Clientes: Los miembros del personal con diferentes roles tienen la capacidad de gestionar varios aspectos de la plataforma, como las cuentas de los clientes, el procesamiento de pedidos y la resolución de problemas.

Roles#

En el ecosistema de BookHarber, podemos identificar varios roles de usuario clave, tales como:

1. Invitado: Usuarios o registrados que pueden avegar por el sitio web, buscar libros y ver ofertas especiales.
2. Cliente: Usuarios registrados que pueden comprar libros, gestionar pedidos, seguir la logística y abrir tickets de soporte.
3. Administrador de la Tienda: Miembros del personal responsables de supervisar la gestión y operaciones generales de la plataforma. Con acceso completo.
4. Gerente de Libros: Miembros del personal a cargo de la gestión de libros y categorías.
5. Agente de Atención al Cliente: Miembros del personal encargados de responder a los tickets de soporte.
6. Proveedor de Logística de Terceros: Socios externos responsables de gestionar y seguir el envío y entrega de pedidos.
7. Personal de Marketing: Miembros del personal responsables de promocionar BookHarber, responsables de gestionar ofertas especiales y eventos.

Diseñando ámbitos para las API REST de BookHarber#

Para implementar eficazmente el sistema RBAC de Logto para BookHarber, ecesitamos diseñar ámbitos que correspondan a las diversas APIs REST. Los ámbitos son permisos que definen el ivel de acceso que un rol específico tiene para cada punto final de la API. Al asignar los ámbitos apropiados a cada rol de usuario, podemos asegurar que los usuarios solo tengan acceso a las acciones y recursos relevantes para su rol.

Diseñemos ámbitos para las siguientes APIs REST:

1. API de Categorías:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. API de Libros:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. API de Clientes:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. API de Pedidos:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. API de Eventos:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. API de Seguimiento de Pedidos:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. API de Tickets:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Asignando ámbitos a Roles#

Ahora que hemos definido los ámbitos apropiados para cada API REST, podemos asignar estos ámbitos a los respectivos roles de usuario en el ecosistema de BookHarber:

Comprender las diferencias entre los ámbitos "list" y "read"#

Para ilustrar aún más las diferencias entre los ámbitos "list" y "read" en el contexto del diseño de API REST y RBAC, consideremos un ejemplo del mundo real que involucra una librería en línea, BookHarber.

Supongamos que BookHarber tiene dos tipos de usuarios: clientes y agentes de atención al cliente. Los clientes pueden crear pedidos, mientras que los agentes de atención al cliente son responsables de ayudar a los clientes con sus pedidos. Echemos un vistazo a cómo se aplican los ámbitos "list" y "read" al recurso API orders en este escenario.

1. Ámbitos de Lista: Un ámbito de "list" permite al usuario acceder a una colección de entidades en el sistema. Por ejemplo, el ámbito list:orders permite a un usuario recuperar una lista de todos los pedidos disponibles. En el contexto de BookHarber, este ámbito podría ser útil para los administradores de tiendas u otros miembros del personal que ecesitan tener una visión general de todos los pedidos en el sistema. Sin embargo, los agentes de atención al cliente o deben poder acceder a la lista completa de pedidos, ya que su rol es ayudar a los clientes individuales con sus pedidos específicos.
2. Ámbitos de Lectura: Un ámbito de "read" otorga al usuario el permiso para acceder a una única entidad con un ID dado. Por ejemplo, el ámbito read:orders permite al usuario ver información detallada sobre un pedido específico por su ID. En el caso de BookHarber, este ámbito es ideal para los agentes de atención al cliente que ecesitan acceder a información sobre el pedido de un cliente en particular. Cuando un cliente abre un ticket de soporte, el agente de atención al cliente puede usar el ID del pedido proporcionado en el ticket para acceder y ver los detalles de ese pedido específico.

Entendiendo la propiedad: ¿Por qué los clientes#

o ecesitan ámbitos de "read" o "list" para sus propios pedidos?

En muchas aplicaciones, es común que los usuarios tengan acceso a sus propios recursos sin otorgarles explícitamente los correspondientes ámbitos de "read" o "list". Esto se debe a que los usuarios se consideran los propietarios de estos recursos y deberían tener aturalmente acceso a ellos. En el caso de uestro ejemplo de BookHarber, los clientes pueden crear pedidos pero o poseen los ámbitos "read:orders" o "list:orders".

El concepto de propiedad juega un papel crucial en la definición del control de acceso para recursos específicos en una API REST. Al reconocer que los usuarios siempre pueden acceder a sus propios recursos, podemos implementar un control de acceso más eficiente y seguro sin otorgar permisos innecesarios. En el caso de BookHarber, esto significa que los clientes aún pueden ver y gestionar sus pedidos sin ecesidad de ámbitos adicionales.

Para demostrar cómo funciona esto, consideremos el punto final GET /orders:

1. Si un usuario tiene el ámbito list:orders (por ejemplo, administradores de tienda o miembros del personal), podrán ver todos los pedidos en el sistema. Esto les proporciona una visión integral de los datos de los pedidos ecesarios para su rol.
2. Si un usuario o tiene el ámbito list:orders (por ejemplo, clientes regulares), el sistema solo devolverá los pedidos que pertenezcan al usuario. Esto garantiza que los clientes aún pueden acceder a su información de pedidos sin que se les otorguen permisos innecesarios.

Al implementar este control de acceso basado en la propiedad, la API puede proporcionar el ivel apropiado de acceso a diferentes roles de usuario mientras mantiene la seguridad y una experiencia de usuario personalizada. En el escenario de BookHarber, el modelo de propiedad permite a los clientes acceder a su información de pedidos sin ecesidad de ámbitos de "read:orders" o "list:orders", simplificando el diseño del control de acceso y mejorando la experiencia de usuario general.

Configuración de ajustes en la Consola de Logto#

Para completar la configuración en la Consola de Logto, sigue estos pasos:

1. Crear una Aplicación de Página Única (SPA) para React: Configura una SPA en la Consola de Logto para tu aplicación React.
2. Crear un Recurso API: Agrega un uevo Recurso API con el identificador https://api.bookharber.com.
3. Definir Ámbitos para el Recurso: Crea los ámbitos ecesarios bajo el Recurso API recién creado.
4. Crear Roles y Asignar Ámbitos: Define los roles de usuario para tu aplicación, y asigna los ámbitos apropiados a cada rol.
5. Asignar Roles a Usuarios: Asigna los roles relevantes a los usuarios en tu aplicación, asegurando que cada usuario (Especialmente el miembro del personal) tiene los permisos correctos en base a su rol.

Proteger API usando ámbitos#

En uestro proyecto de ejemplo, BookHarber, usamos Express para el servicio de backend y React para la página web de frontend. Esta sección proporcionará una breve descripción de cómo podemos integrar las características de RBAC de Logto en estas tecnologías populares para asegurar uestra aplicación.

El doc completo: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

Para inicializar Logto en tu aplicación React, sigue la documentación proporcionada aquí:: https://docs.logto.io/docs/recipes/integrate-logto/react/

Además de la configuración básica, ecesitarás especificar el "recurso" y los "ámbitos" en la configuración:

Aquí hay un ejemplo de cómo hacer una petición de API usando Logto:

Backend#

Para proteger la API, sigue: https://docs.logto.io/docs/recipes/protect-your-api/

Además del código de ejemplo (https://docs.logto.io/docs/recipes/protect-your-api/node), ecesitaremos agregar la validación de ámbitos:

Conclusión#

El sistema RBAC de Logto es una herramienta poderosa para gestionar el control de acceso y la seguridad en las aplicaciones modernas. Al aprovechar las características de RBAC de Logto, puedes asegurar que los usuarios tengan acceso apropiado a los recursos en función de sus roles, protegiendo los datos sensibles y las funciones de acceso o autorizado.

En este artículo, exploramos un ejemplo del mundo real de una librería en línea, BookHarber, y demostramos cómo diseñar ámbitos, asignarlos a roles de usuario e implementar las características de RBAC de Logto tanto en el frontend como en el backend de la aplicación.

Al aplicar estos conceptos y técnicas a tus proyectos, puedes mejorar la seguridad y el control de acceso de tus aplicaciones, proporcionando una experiencia de usuario segura y fluida. Ya sea que estés trabajando en una plataforma de comercio electrónico, un sistema de gestión de contenidos o cualquier otro proyecto que requiera control de acceso basado en roles, el sistema RBAC de Logto ofrece una solución flexible y eficiente para satisfacer tus ecesidades de control de acceso.