Dominando RBAC o Logto: Um Exemplo Abrangente do Mundo Real

Introdução#

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

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

Apresentando o BookHarber: Um caso de uso de livraria online#

Para demonstrar efetivamente os recursos de RBAC do Logto, vamos usar um exemplo real: o BookHarber, uma livraria online. O BookHarber oferece uma ampla gama de recursos para clientes e funcionários, garantindo uma experiência de compra contínua e segura.

As principais características do BookHarber incluem:

1. Navegação e Compra de Livros: Os usuários podem facilmente procurar e comprar livros de uma coleção diversificada, abrangendo vários gêneros e autores.
2. Gestão de Pedidos e Rastreamento de Logística: Os clientes registados podem gerir os seus pedidos, rastrear envios e receber atualizações sobre as suas compras.
3. Ofertas Especiais e Atividades Festivas: O BookHarber oferece descontos exclusivos e promoções 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 resolver qualquer problema ou preocupação que possam encontrar, recebendo assistência rápida da equipe do BookHarber.
5. Gestão de Clientes: Membros da equipe com diferentes funções têm a capacidade de gerir vários aspectos da plataforma, tais como contas de clientes, processamento de pedidos e resolução de problemas.

Funções#

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

1. Hóspede: Usuários ão registados que podem avegar o site, procurar livros e ver ofertas especiais.
2. Cliente: Usuários registados que podem comprar livros, gerir encomendas, rastrear logística e abrir tickets de suporte.
3. Administrador da Loja: Membros da equipe responsáveis por supervisionar a gestão geral e as operações da plataforma. Com acesso total.
4. Gerente de Livros: Membros da equipe encarregados da gestão de livros e categorias.
5. Agente de Serviço ao Cliente: Membros da equipe encarregados de responder aos tickets de suporte.
6. Fornecedor de Logística Terceirizado: Parceiros externos responsáveis pela gestão e rastreamento do envio e entrega de encomendas.
7. Equipe de Marketing: Membros da equipe responsáveis por promover o BookHarber, responsáveis por gerir ofertas especiais e eventos.

Desenho de escopos para as APIs REST do BookHarber#

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

Vamos desenhar 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 Bilhetes:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Atribuir escopos às Funções#

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

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

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

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

1. Escopos de Lista: Um escopo de "lista" permite ao usuário acessar uma coleção de entidades o sistema. Por exemplo, o escopo list:orders permite ao usuário recuperar uma lista de todos os pedidos disponíveis. No contexto do BookHarber, este escopo poderia 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, os agentes de serviço ao cliente ão devem poder acessar a lista completa de pedidos, pois seu papel é ajudar os clientes individuais com seus pedidos específicos.
2. Escopos de Leitura: Um escopo de "leitura" 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 pelo seu ID. No caso da BookHarber, este escopo é ideal para agentes de serviço ao cliente que precisem acessar informações sobre um pedido específico do cliente. Quando um cliente abre um ticket de suporte, o agente de serviço ao cliente pode usar o ID do pedido fornecido o ticket para acessar e visualizar os detalhes desse pedido específico.

Entendendo a propriedade: Por que os clientes#

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

Em muitas aplicações, é comum que os usuários tenham acesso aos seus próprios recursos sem explicitamente conceder-lhes os escopos "read" ou "list" correspondentes. Isso ocorre porque os usuários são considerados os proprietários desses recursos e devem aturalmente ter acesso a eles. No caso do osso exemplo do 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 sempre podem 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 gerir os seus pedidos sem ecessitar de quaisquer escopos adicionais.

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

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

Ao implementar este controle de acesso baseado em propriedade, a API pode fornecer o ível de acesso apropriado a diferentes funções de usuário enquanto mantém a segurança e uma experiência de usuário sob medida. 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 de controle de acesso e aprimorando a experiência geral do usuário.

Configurando as definições#

o Console Logto

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

1. Criar uma Aplicação de Página Única (SPA) para React: Configure um SPA o Console Logto para a sua aplicação React.
2. Criar um Recurso de API: Adicione um ovo Recurso de API com o identificador https://api.bookharber.com.
3. Definir Escopos para o Recurso: Crie os escopos ecessários sob o ovo Recurso de API criado.
4. Criar Funções e Atribuir Escopos: Defina as funções de usuário para a 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 a sua aplicação, garantindo que cada usuário (especialmente membros da equipe) possui as permissões corretas baseadas a sua função.

Proteger API usando escopos#

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

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

Frontend#

Para inicializar o Logto a 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 "recurso" e os "escopos" a configuração:

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

Backend#

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

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

Conclusão#

O sistema de RBAC do Logto é uma ferramenta poderosa para gerir o controle de acesso e a segurança em aplicações modernas. Ao aproveitar os recursos de RBAC do 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 de acesso ão autorizado.

Neste artigo, exploramos um exemplo real de uma livraria online, BookHarber, e demonstramos como projetar escopos, atribuí-los a funções de usuário e implementar os recursos de RBAC do Logto tanto o frontend quanto o 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 das suas aplicações, proporcionando uma experiência de usuário contínua e segura. Quer esteja a trabalhar uma plataforma de comércio eletrónico, um sistema de gestão de conteúdo ou em qualquer outro projeto que exija controle de acesso baseado em funções, o sistema de RBAC do Logto oferece uma solução flexível e eficiente para atender às suas ecessidades de controle de acesso.