CIAM 102: Autorização e Controle de Acesso baseado em Papel

Contexto#

No artigo anterior, introduzimos o conceito de autenticação (AuthN) e autorização (AuthZ), juntamente com alguns termos confusos: Identidade, Organização, Locatário, etc.

Organização e Locatário 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?#

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

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

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

O modelo básico de autorização#

Este é um dos modelos AuthZ mais comuns: Se a IDENTIDADE executar ** AÇÃO ** em RECURSO, então ACEITAR ou NEGAR.

No exemplo do Notion, o modelo é PESSOA executa VISUALIZAÇÃO em PÁGINA.

Se a página for privada:

• Você receberá ACEITAR ao executar VISUALIZAÇÃO em sua PÁGINA.
• Todos os outros devem receber NEGAR ao executar VISUALIZAÇÃO em sua PÁGINA.

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

Controle de Acesso Baseado em Função#

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

• Os clientes podem visualizar e encomendar livros, bem como visualizar 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, uma vez que é necessário usar um URL válido como indicador. Portanto, definimos dois recursos:

• Livros: https://api.livraria.io/livros
• Pedidos: https://api.livraria.io/pedidos

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

Definir permissões#

Como introduzimos o conceito de recurso, no Logto, também impomos que as permissões devem pertencer a um recurso, em reverso, recursos podem ter permissões. Vamos adicionar algumas permissões aos recursos:

• Livros: leia, crie, delete
• Pedidos: leia, leia:próprio, crie:próprio, delete

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

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

• A permissão leia no recurso Livros significa a ação de ler livros arbitrários.
• A permissão crie:próprio no recurso Pedidos significa a ação de criar pedidos que pertencem ao usuário atual.

Definir papéis#

Em resumo, um papel é um grupo de permissões. Vamos criar dois papéis cliente e vendedor e atribuir permissões a eles como mostrado abaixo:

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

Atribuir papéis aos usuários#

Assim como a atribuição de papel-permissão, a atribuição de usuário-papel também é uma relação de muitos-para-muitos. Portanto, você pode atribuir vários papéis a um único usuário, e um único papel pode ser atribuído 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, permissões são sempre "positivas", significando que o julgamento da autorização é simples: se um usuário tem a permissão, ele aceita; caso contrário, rejeita.

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

• Alice quer adicionar um novo livro à venda:
  • Usuário Alice executa crie no recurso Livros (https://api.livraria.io/livros).
  • Como Alice tem a permissão crie de Livros de acordo com seu papel vendedor, o resultado é ✅ ACEITAR.
• Alice quer visualizar todos os pedidos para ver se a venda atende às suas expectativas:
  • Usuário Alice executa leia no recurso Pedidos (https://api.livraria.io/pedidos).
  • Como Alice tem a permissão leia de Pedidos de acordo com seu papel vendedor, o resultado é ✅ ACEITAR.
• Bob quer navegar na lista de livros para ver se há algum livro que queira comprar.
  • Usuário Bob executa leia no recurso Livros (https://api.livraria.io/livros).
  • Como Bob tem a permissão leia de Livros de acordo com seu papel cliente, o resultado é ✅ ACEITAR.
• Bob quer visualizar o pedido de Carol.
  • Como é o pedido de outra pessoa, a permissão leia:próprio de Pedidos não funciona aqui.
  • Usuário Bob executa leia no recurso Pedidos (https://api.livraria.io/pedido).
  • Como Bob não tem a permissão leia de Pedidos, o resultado é ❌ NEGAR.

Outros níveis RBAC#

Existem quatro níveis no modelo NIST RBAC:

• RBAC Plano
• RBAC Hierárquico
• RBAC Restrito
• RBAC Simétrico

Veja o artigo para mais detalhes se estiver interessado.

Logto agora tem a implementação de Nível 1 e evoluirá para níveis mais altos com base no feedback da comunidade. Não hesite em nos informar se um nível mais alto se adequa às suas necessidades!

Na prática#

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

• Desenvolvimento de cliente e servidor auth
• Design de banco de dados para RBAC
• Validação em diferentes serviços
• Conformidade de segurança e padrão aberto
• Gerenciamento de papel, 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 RBAC no Logto.

Notas finais#

RBAC é um poderoso modelo de gerenciamento de acesso para a maioria dos casos, mas não há solução mágica. 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?