Dominando o RBAC em Logto: Um exemplo prático abrangente

Introdução#

Controle de acesso e segurança são aspectos essenciais de aplicações modernas, garantindo que os usuários tenham acesso apropriado aos recursos. O Controle de Acesso Baseado em Funções (RBAC) da Logto oferece aos desenvolvedores uma maneira eficiente de gerenciar o controle de acesso e a segurança em suas aplicações. Neste artigo, vamos explorar as poderosas funcionalidades da implementação RBAC da Logto usando um exemplo prático, ajudando você a entender e aplicar esses conceitos aos seus projetos.

Ao examinar trechos de código frontend e backend, você obterá uma perspectiva abrangente sobre como integrar o RBAC da Logto em sua stack de aplicativos. No final deste artigo, você estará bem equipado para aproveitar os recursos RBAC de Logto para melhorar a segurança e o controle de acesso de seu projeto.

Apresentando BookHarber: Um caso de uso de livraria online#

Para demonstrar efetivamente os recursos RBAC de Logto, usaremos um exemplo prático: BookHarber, uma livraria virtual. A BookHarber oferece uma ampla gama de recursos para clientes e funcionários, garantindo uma experiência de compra segura e tranquila.

Principais recursos do BookHarber incluem:

1. Procurar e Comprar Livros: Os usuários podem facilmente procurar e comprar livros em uma coleção diversificada, que abrange vários gêneros e autores.
2. Gerenciamento de pedidos e rastreamento de logística: Os clientes registrados podem gerenciar seus pedidos, rastrear o envio e receber atualizações sobre suas compras.
3. Ofertas especiais e atividades de feriados: BookHarber oferece descontos e promoções exclusivas durante eventos especiais e feriados para engajar e recompensar sua base de clientes.
4. Suporte ao cliente: Os clientes podem abrir tickets de suporte para tratar de quaisquer preocupações ou problemas que possam encontrar, recebendo assistência rápida da equipe de BookHarber.
5. Gerenciamento de clientes: Membros da equipe com diferentes funções têm a capacidade de gerenciar vários aspectos da plataforma, como contas de clientes, processamento de pedidos e resolução de problemas.

Funções#

No ecossistema BookHarber, podemos identificar várias funções-chave do usuário, como:

1. Convidado: Usuários ão registrados que podem avegar o site, procurar por livros e ver ofertas especiais.
2. Cliente: Usuários registrados que podem comprar livros, gerenciar pedidos, rastrear logística e abrir tickets de suporte.
3. Administrador de loja: Membros da equipe responsáveis por supervisionar o gerenciamento geral e operações da plataforma. Com acesso total.
4. Gerente de livros: Membros da equipe encarregados do gerenciamento de livros e categorias.
5. Agente de atendimento ao cliente: Membros da equipe encarregados de responder aos tickets de suporte.
6. Provedor de logística terceirizado: Parceiros externos responsáveis por gerenciar e rastrear o envio e entrega de pedidos.
7. Equipe de marketing: Membros da equipe responsáveis por promover o BookHarber, responsáveis por gerenciar ofertas especiais e eventos.

##Designando escopos para APIs REST de BookHarber

Para implementar efetivamente o sistema RBAC de Logto para BookHarber, precisamos projetar escopos que correspondam às várias APIs REST. Escopos são permissões que definem o ível de acesso que uma função específica tem para cada endpoint da API. Ao atribuir os escopos apropriados a cada função de usuário, podemos garantir que os usuários tenham apenas acesso às ações e recursos relevantes para sua função.

Vamos projetar escopos para as seguintes APIs REST:

1. API de Categorias:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. API de Livros:
   • 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 Rastreamento 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

Atribuindo escopos a funções#

Agora que definimos os escopos apropriados para cada API REST, podemos atribuir esses escopos às respectivas funções de usuário o ecossistema BookHarber:

Compreendendo as diferenças entre os escopos "list" e "read"#

Para ilustrar ainda mais as diferenças entre os escopos "list" e "read" o contexto do design de API REST e RBAC, vamos considerar um exemplo prático envolvendo uma livraria online, BookHarber.

Suponha que BookHarber tenha dois tipos de usuários: clientes e agentes de atendimento ao cliente. Os clientes podem criar pedidos, enquanto os agentes de atendimento ao cliente são responsáveis por ajudar os clientes com seus pedidos. Vamos dar uma olhada em como os escopos "list" e "read" se aplicam ao recurso API orders este cenário.

1. Escopos da Lista: Um escopo "list" permite ao usuário acessar uma coleção de entidades o sistema. Por exemplo, o escopo list:orders permite a um usuário recuperar uma lista de todos os pedidos disponíveis. No contexto de BookHarber, este escopo pode ser útil para administradores de loja ou outros membros da equipe que precisam ter uma visão geral de todos os pedidos o sistema. No entanto, agentes de atendimento ao cliente ão devem ser capazes de acessar a lista completa de pedidos, pois seu papel é ajudar os clientes individuais com seus pedidos específicos.
2. Escopos de Leitura: Um escopo "read" concede ao usuário permissão para acessar uma única entidade com um determinado ID. Por exemplo, o escopo read:orders permite ao usuário visualizar informações detalhadas sobre um pedido específico por seu ID. No caso do BookHarber, este escopo é ideal para agentes de atendimento ao cliente que precisam acessar informações sobre um pedido específico do cliente. Quando um cliente abre um ticket de suporte, o agente de atendimento ao cliente pode usar o ID do pedido fornecido o ticket para acessar e visualizar os detalhes desse pedido específico.

Compreendendo a propriedade: Por que os clientes#

ão precisam de escopos "read" ou "list" para seus próprios pedidos

Em muitas aplicativos, é comum que os usuários tenham acesso aos seus próprios recursos sem conceder explicitamente os escopos "read" ou "list" correspondentes. Isso ocorre porque os usuários são considerados proprietários desses recursos e devem aturalmente ter acesso a eles. No caso do osso exemplo BookHarber, os clientes podem criar pedidos, mas ão possuem os escopos "read:orders" ou "list:orders".

O conceito de propriedade desempenha um papel crucial a definição do controle de acesso para recursos específicos em uma API REST. Ao reconhecer que os usuários podem sempre acessar seus próprios recursos, podemos implementar um controle de acesso mais eficiente e seguro sem conceder permissões desnecessárias. No caso do BookHarber, isso significa que os clientes ainda podem visualizar e gerenciar seus pedidos sem precisar de quaisquer escopos adicionais.

Para demonstrar como isso funciona, vamos considerar o endpoint GET /orders:

1. Se um usuário tem o escopo list:orders (por exemplo, administradores de loja ou membros da equipe), eles poderão ver todos os pedidos o sistema. Isso lhes proporciona uma visão abrangente dos dados do pedido ecessários para seu papel.
2. Se um usuário ão tem o escopo list:orders (por exemplo, clientes regulares), o sistema retornará apenas os pedidos que pertencem ao usuário. Isso garante que os clientes ainda possam acessar suas informações de pedido sem receber permissões desnecessárias.

Ao implementar este controle de acesso baseado em propriedade, a API pode fornecer o ível apropriado de acesso a diferentes funções de usuário, mantendo a segurança e uma experiência de usuário personalizada. No cenário do BookHarber, o modelo de propriedade permite que os clientes acessem suas informações de pedido sem a ecessidade de escopos "read:orders" ou "list:orders", simplificando o design do controle de acesso e aprimorando a experiência geral do usuário.

Configurando configurações#

o Console Logto

Para concluir a configuração o Console da Logto, siga estas etapas:

1. Criar uma Aplicação de Página Única (SPA) para React: Configure um SPA o Console Logto para sua aplicação React.
2. Criar um recurso API: Adicione um ovo Recurso API com o identificador https://api.bookharber.com.
3. Definir Escopos para o Recurso: Crie os escopos ecessários sob o Recurso API recém-criado.
4. Criar Funções e Atribuir Escopos: Defina as funções de usuário para sua aplicação e atribua os escopos apropriados a cada função.
5. Atribuir Funções aos Usuários: Atribua as funções relevantes aos usuários em sua aplicação, garantindo que cada usuário (Especialmente membro da equipe) tenha as permissões corretas com base em sua função.

Protegendo API usando escopos#

Em osso projeto exemplo, BookHarber, usamos Express para o serviço backend e React para a página web frontend. Esta seção fornecerá uma breve visão geral de como podemos integrar os recursos RBAC de Logto essas tecnologias populares para proteger ossa aplicação.

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

Frontend#

Para inicializar Logto em sua aplicação React, siga a documentação fornecida aqui:: https://docs.logto.io/docs/recipes/integrate-logto/react/

Além da configuração básica, você precisará especificar o "resource" e os "scopes" a configuração:

Aqui está um exemplo de como fazer uma solicitação API usando Logto:

Backend#

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

Além do código exemplo (https://docs.logto.io/docs/recipes/protect-your-api/node), precisaremos adicionar a validação do escopo:

Conclusão#

O sistema RBAC de Logto é uma ferramenta poderosa para gerenciar o controle de acesso e a segurança em aplicações modernas. Ao aproveitar os recursos RBAC de Logto, você pode garantir que os usuários tenham acesso apropriado aos recursos com base em suas funções, protegendo dados e funcionalidades sensíveis contra acesso ão autorizado.

Neste artigo, exploramos um exemplo prático de uma livraria online, BookHarber, e demonstramos como criar escopos, atribuir a funções de usuário e implementar os recursos RBAC de Logto em ambos, frontend e backend da aplicação.

Ao aplicar esses conceitos e técnicas aos seus projetos, você pode melhorar a segurança e o controle de acesso de suas aplicações, proporcionando uma experiência de usuário tranquila e segura. Independente de você estar trabalhando em uma plataforma de comércio eletrônico, um sistema de gestão de conteúdo, ou qualquer outro projeto que exija controle de acesso baseado em funções, o sistema RBAC de Logto oferece uma solução flexível e eficiente para atender às suas ecessidades de controle de acesso.