Controle de acesso baseado em papel

O controle de acesso baseado em papel (RBAC) é um método de atribuir permissões a usuários com base em seus papéis. Considere usar RBAC nos seguintes cenários:

• Você tem vários usuários com diferentes necessidades de acesso: RBAC é ideal quando os usuários precisam de permissões variadas com base em papéis, como administrador, editor ou visualizador.
• Você precisa simplificar o gerenciamento de permissões: É eficiente para gerenciar grandes grupos de usuários atribuindo papéis em vez de definir permissões individualmente.
• Seu aplicativo atende a diferentes departamentos ou equipes: É útil em cenários onde diferentes grupos requerem níveis distintos de acesso a recursos.

Entenda como funciona o controle de acesso baseado em papel

Permissões (Escopos)

Permissão refere-se à autorização para acessar um [recurso de API]. No mundo real, entidades como pedidos, produtos e documentos podem ser designadas como recursos, e várias ações podem ser atribuídas.

Exemplos de permissões, incluindo a capacidade de editar um pedido, ler um documento e excluir um produto, são os seguintes:

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

A figura acima mostra que a permissão read:item no recurso https://api-1.store.io é diferente da permissão read:item no recurso https://api-2.store.io.

Se nenhum recurso de API for fornecido, a permissão será tratada como "para OIDC". Geralmente, isso não é o que você deseja no RBAC.

Papéis

Papéis são um agrupamento de permissões que podem ser atribuídos a usuários. Eles também fornecem uma maneira de agregar permissões definidas para diferentes APIs, tornando a adição, remoção ou ajuste de permissões mais eficiente do que atribuí-las individualmente aos usuários.

Aqui está um exemplo de um papel order_admin com várias permissões para dois recursos:

Não há problema em ter sobreposição de permissões entre papéis.

Exemplo: Uma livraria online

Digamos que você tenha uma livraria online para gerenciar. Aqui, simplificamos bastante o modelo de controle de acesso para fins de demonstração.

O modelo é dividido em dois principais recursos de API: pedidos e produtos. Eles têm diferentes indicadores de recurso, conforme abaixo:

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

Para cada recurso, você gostaria de separar permissões em leitura, escrita e exclusão. Então você define seis permissões no total:

• https://api.store.io/orders
  • Permissão read:order
  • Permissão write:order
  • Permissão delete:order
• https://api.store.io/products
  • Permissão read:product
  • Permissão write:product
  • Permissão delete:product

Aqui está a ilustração deste modelo:

Você quer ter dois tipos de administrador, administrador de pedidos e administrador de produtos:

• Administrador de pedidos pode gerenciar pedidos e ver produtos (já que pedidos consistem em produtos), mas não pode gerenciar produtos.
• Administrador de produtos pode gerenciar produtos, e eles não devem estar cientes de quaisquer pedidos.

Então você cria dois papéis, order_admin e product_admin, com as permissões:

• 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

Aqui está a ilustração desses dois papéis:

Não há problema em atribuir tanto order_admin quanto product_admin a um usuário, então ele terá todas as seis permissões que você acabou de definir.

Observe que o administrador de pedidos compartilha a permissão read:product com o administrador de produtos, e as permissões finais que um usuário possui são a união de todas as permissões dos papéis aos quais ele foi atribuído.