CIAM 102: Autorização e Controle de Acesso Baseado em Funções

Contexto#

No artigo anterior, apresentamos o conceito de autenticação (AuthN) e autorização (AuthZ), junto com alguns termos que causam dor de cabeça: Identidade, Organização, Inquilino, etc.

Organização e inquilino são ótimos para agrupar identidades, mas eles levam a uma democracia absoluta: todos podem fazer qualquer coisa neste sistema. Enquanto a utopia ainda é um mistério, vamos dar uma olhada na governança de acesso: Autorização (AuthZ).

Por que precisamos de autorização?#

O Notion é um ótimo exemplo. Para cada página que você possui, você pode escolher mantê-la privada, acessível apenas para você, ou compartilhá-la com amigos, ou até mesmo com o público.

Ou, para uma livraria online, você quer que todos possam ver todos os livros, mas que os clientes só possam ver seus próprios pedidos, e os vendedores possam gerenciar apenas os livros em suas lojas.

AuthZ e AuthN são componentes essenciais de um modelo de negócio complexo. Eles geralmente andam de mãos dadas; AuthZ verifica o acesso de um usuário, enquanto AuthN autentica identidades. Ambos são necessários para um sistema seguro.

O modelo básico de autorização#

Aqui está um dos modelos AuthZ mais comuns: Se IDENTIDADE realiza AÇÃO em RECURSO, então ACEITE ou NEGA.

No exemplo do Notion, o modelo é PESSOA realiza VIZUALIZAÇÂO na PÁGINA.

Se a página é privada:

• Você receberá ACEITE ao realizar VIZUALIZAÇÃO na sua PÁGINA.
• Todo mundo deve receber NEGA ao realizar VIZUALIZAÇÃO na sua PÁGINA.

Com base no consenso, a indústria desenvolveu várias tecnologias de autorização, como o Controle de Acesso Baseado em Funções (RBAC), Controle de Acesso Baseado em Atributos (ABAC). Hoje, vamos nos concentrar no modelo RBAC do NIST Nível 1: RBAC Plano.

Controle de Acesso Baseado em Funções#

Vamos estender o exemplo da livraria. Digamos que temos muitos clientes, mas apenas um vendedor:

• Os clientes podem ver e pedir livros, bem como ver seus próprios pedidos.
• O vendedor pode visualizar, criar e deletar livros, e gerenciar pedidos de clientes.

Definir recursos#

No Logto, um recurso (ou seja, Recurso API) geralmente representa um conjunto de entidades ou itens, já que é necessário usar uma URL válida como indicador. Portanto, definimos dois recursos:

• Livros: https://api.bookstore.io/books
• Pedidos: https://api.bookstore.io/orders

Uma das vantagens de impor o formato de URL é que ele pode ser mapeado para um endereço real do seu serviço de API, o que melhora a legibilidade e reconhecibilidade ao se integrar com outros componentes no sistema.

Definir permissões#

Como introduzimos o conceito de recurso, no Logto, também exigimos que as permissões devem pertencer a um recurso, em reverso, os recursos podem ter permissões.

Vamos adicionar algumas permissões aos recursos:

• Livros: read, create, delete
• Pedidos: read, read:self, create:self, delete

Embora não haja requisito de nome de uma permissão, temos a seguinte convenção:

`` <ação>[:<destino>]

Enquanto <ação> é necessário para descrever uma permissão, :<destino> pode ser ignorado para descrever um alvo geral, ou seja, para todas as entidades ou itens no recurso. Por exemplo:

• A permissão read no recurso Livros significa a ação de ler livros arbitrários.
• A permissão create:self no recurso Pedidos significa a ação de criar pedidos que pertencem ao usuário atual.

Definir funções#

Em resumo, uma função é um grupo de permissões. Vamos criar duas funções cliente e vendedor e assignar permissões a elas como abaixo:

Você pode notar que a atribuição de permissão-função é de muitos para muitos.

Assignar funções aos usuários#

Assim como a atribuição de função-permissão, a atribuição de usuário-função também é um relacionamento de muitos para muitos. Portanto, você pode atribuir várias funções a um único usuário, e uma única função pode ser atribuída a vários usuários.

Conectar os pontos#

Aqui está um diagrama de relacionamento completo para o modelo RBAC de Nível 1 no Logto:

No modelo RBAC, as permissões são sempre "positivas", o que significa que o julgamento de autorização é simples: se um usuário tem a permissão, então aceita; caso contrário, rejeita.

Vamos dizer que Alice tem a função vendedor, Bob e Carol têm a função cliente. Vamos descrever as ações em linguagem natural primeiro, e transpilá-las para o formato padrão de autorização: IDENTIDADE realiza AÇÃO em RECURSO, finalmente dando a conclusão.

• Alice quer adicionar um novo livro para venda:
  • Usuário Alice realiza create no recurso Livros (https://api.bookstore.io/books).
  • Como Alice foi atribuída a permissão create de Livros de acordo com sua função vendedor, o resultado é ✅ ACEITE.
• Alice quer ver todos os pedidos para ver se a venda atende suas expectativas:
  • Usuário Alice realiza read no recurso Pedidos (https://api.bookstore.io/orders).
  • Como Alice foi atribuída a permissão read de Pedidos de acordo com sua função vendedor, o resultado é ✅ ACEITE.
• Bob quer navegar pela lista de livros para ver se há algum livro que eles queiram comprar.
  • Usuário Bob realiza read no recurso Livros (https://api.bookstore.io/books).
  • Como Bob foi atribuída a permissão read de Livros de acordo com sua função cliente, o resultado é ✅ ACEITE.
• Bob quer ver o pedido da Carol.
  • Como é o pedido de outra pessoa, a permissão read:self de Pedidos não funciona aqui.
  • Usuário Bob realiza read no recurso Pedidos (https://api.bookstore.io/order).
  • Como Bob não tem permissão read de Pedidos, o resultado é ❌ NEGA.

Outros níveis de RBAC#

Existem quatro níveis no modelo RBAC do NIST:

• RBAC plano
• RBAC hierárquico
• RBAC restrito
• RBAC simétrico

Veja o artigo para detalhes se você estiver interessado.

O Logto agora tem a implementação do Nível 1 e vai progredir para níveis mais altos com base no feedback da comunidade. Não hesite em nos dizer se um nível superior se encaixa na sua necessidade!

Na prática#

Além da teoria, ainda temos trabalhos técnicos pesados a completar para fazer o modelo funcionar como esperado:

• Desenvolvimento do cliente e do servidor de autenticação
• Projeto de banco de dados para RBAC
• Validação em diferentes serviços
• Segurança e conformidade com padrões abertos
• Gerenciamento de função, permissão, recurso e atribuição

Não entre em pânico. Nós levamos isso em consideração e adicionamos suporte pronto para uso para cobrir tudo isso. Confira a 🔐 Receita RBAC para aprender como usar o RBAC no Logto.

Notas finais#

O RBAC é um poderoso modelo de gerenciamento de acesso para a maioria dos casos, mas não há bala de prata. Ainda temos algumas perguntas:

• Preciso de níveis altos de RBAC?
• Como o RBAC se compara a outros modelos de autorização?
• Como definir o modelo de autorização entre diferentes Organizações?