Português (Brasil)

ciam
auth
autorização

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

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).

Gao

Founder

2/5/2023

Pare de perder semanas com autenticação de usuários

Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.

Começar

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.

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?

Contexto#

Por que precisamos de autorização?#

O modelo básico de autorização#

Controle de Acesso Baseado em Funções#

Definir recursos#

Definir permissões#

Definir funções#

Assignar funções aos usuários#

Conectar os pontos#

Outros níveis de RBAC#

Na prática#

Notas finais#

Contexto#

Por que precisamos de autorização?#

O modelo básico de autorização#

Controle de Acesso Baseado em Funções#

Definir recursos#

Definir permissões#

Definir funções#

Assignar funções aos usuários#

Conectar os pontos#

Outros níveis de RBAC#

Na prática#

Notas finais#

Contexto

Por que precisamos de autorização?

O modelo básico de autorização

Controle de Acesso Baseado em Funções

Definir recursos

Definir permissões

Definir funções

Assignar funções aos usuários

Conectar os pontos

Outros níveis de RBAC

Na prática

Notas finais

Contexto

Por que precisamos de autorização?

O modelo básico de autorização

Controle de Acesso Baseado em Funções

Definir recursos

Definir permissões

Definir funções

Assignar funções aos usuários

Conectar os pontos

Outros níveis de RBAC

Na prática

Notas finais