## Contexto No [artigo anterior](/ciam-101-intro-authn-sso/), 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? A autorização (AuthZ) responde à pergunta "O que você pode fazer?" 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](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ções O modelo RBAC do NIST deixou muitas coisas em aberto para proporcionar flexibilidade e adaptabilidade para vários cenas. O Logto agora adota a definição do Nível 1 com um conceito adicional "Recurso" (ou seja, API Recurso). 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. 🤔 Os recursos devem ser divididos de acordo com as necessidades do negócio. Não há abordagem única para todos; a decisão deve ser tomada caso a caso. O exemplo neste artigo que divide Livros e Pedidos pode ser adequado para microsserviços, mas não para um arquitetura monolítica. ### 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: `` ` [:]` Enquanto `` é necessário para descrever uma permissão, `:` 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: ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` 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: ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 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](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 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](https://docs.logto.io/docs/recipes/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? 🔥 Fique ligado. Nos vemos no CIAM 103!