## Contexto No [artigo anterior](/ciam-101-intro-authn-sso/), 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? Autorização (AuthZ) responde à pergunta “O que você pode fazer?” 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Nível 1: RBAC Plano. ## Controle de Acesso Baseado em Função O modelo NIST RBAC deixou muitas coisas abertas para fornecer flexibilidade e adaptabilidade para vários cenários. Logto agora adota a definição de Nível 1 com um conceito adicional "Recurso" (ou seja, Recurso API). 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. 🤔 Recursos devem ser divididos de acordo com as necessidades do negócio. Não existem soluções universais; a decisão deve ser tomada caso a caso. O exemplo neste artigo que divide Livros e Pedidos pode ser adequado para micro serviços, mas não para uma arquitetura monolítica. ### 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 `` é necessário para descrever uma permissão, `:` 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: ```mermaid erDiagram Paper-Cliente { permission Livros "leia" permission Pedidos "leia:próprio" permission Pedidos "crie:próprio" } Paper-Vendedor { permission Livros "leia" permission Livros "crie" permission Livros "delete" permission Pedidos "leia" permission Pedidos "delete" } ``` 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: ```mermaid erDiagram "Usuário" }|--|{ Papel : maps Papel }|--|{ "Permissão" : maps "Recurso API" ||--|{ "Permissão" : contains ``` 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](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) 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](https://docs.logto.io/docs/receitas/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? 🔥 Fique ligado. Nos vemos no CIAM 103!