APRENDER. PRATICAR. EVOLUIR.Separar acesso à função e acesso ao registo
Um utilizador pode chamar GET de relatórios sem poder ler todos os relatórios existentes. A autenticação identifica um principal no contexto do emissor; a autorização decide se esse principal pode executar esta ação neste recurso. O exercício tem report-a, report-a-private e report-b. Todos usam o mesmo mecanismo de token, mas os objetos têm tenants e relações diferentes. Verificar apenas que o utilizador tem sessão, ou apenas que o endpoint exige autenticação, deixa a decisão por objeto por resolver. Desenha uma matriz de sujeitos, ações e recursos antes de implementar. Inclui leitura, alteração e operações administrativas, porque o comportamento autorizado numa função não se transfere automaticamente para outra.
Conservar a fronteira entre tenants
No modelo, analyst-a tem uma relação de leitura com report-a em fund-a. O mesmo identificador aparece na lista de leitores de report-b em fund-b, mas o token pertence a fund-a: o pedido é recusado. Uma relação isolada não substitui a fronteira do tenant. O tenant é uma claim privada deste exercício, não um campo universal obrigatório do protocolo. Em produção, a origem e a autoridade dos atributos precisam de ser definidas. Um parâmetro de rota ou header enviado pelo cliente não deve substituir silenciosamente o contexto autorizado. Confirma também que consultas, caches, tarefas assíncronas e exportações mantêm essa fronteira; proteger o formulário inicial não protege automaticamente todos os percursos de acesso.
Scopes não substituem relações do negócio
O scope reports:read permite considerar uma leitura, mas report-a-private só tem analyst-b como leitor. Analyst-a é recusado apesar de estar no mesmo tenant e ter o scope certo. Para alterar report-a, o modelo exige reports:write e uma relação de editor. Dar esse scope a analyst-a não o transforma em editor; editor-a com o scope correto passa. O exercício compara scopes completos: reports:read-all não satisfaz reports:read por conter texto semelhante. A política é um exemplo de combinação de atributos e relações. Uma organização pode usar outras regras, mas precisa de explicar quem gere essas relações, quando se atualizam e qual decisão ocorre quando os dados necessários estão ausentes.
Aplicar a decisão no ponto que controla o efeito
Esconder um botão no cliente melhora a interface, mas não impede pedidos diretos. A decisão deve ser aplicada num ponto de confiança que controle acesso ou alteração. Um gateway pode validar o token sem conhecer as relações de cada relatório; o serviço continua a precisar da informação necessária para decidir. Evita que uma validação de leitura seja tomada como permissão de escrita. Em fluxos de alteração, considera também mudanças entre a verificação e o efeito: o recurso pode mudar de tenant ou estado durante a operação. A estratégia concreta depende do armazenamento e da transação. O laboratório apenas calcula decisões sobre objetos em memória; não demonstra atomicidade ou isolamento de uma base de dados real.
Testar recusas e acessos legítimos
Prepara pares de testes com identidade válida: objeto próprio e alheio, mesmo tenant e outro tenant, scope correto e insuficiente, leitor e editor. Acrescenta recurso inexistente, ação não prevista e estado de autorização indisponível. Na fixture, a decisão padrão é recusar e a indisponibilidade não alarga permissões. O diagnóstico interno identifica a razão; a resposta externa deve seguir a política de divulgação do serviço, podendo ocultar a existência de objetos. Identificadores aleatórios reduzem facilidade de descoberta, mas não substituem autorização. Depois de corrigir uma falha, procura a mesma omissão em listagens, downloads, endpoints aninhados e operações em lote. Regista cobertura e lacunas para que a equipa RUN saiba o que foi efetivamente ensaiado.
# Fixture decisions
# report-a + analyst-a + read -> permitted
# report-a-private + analyst-a + read -> object-relationship
# report-b + fund-a token + read -> tenantAnalyst-a lê report-a, mas não report-a-private no mesmo tenant nem report-b noutro tenant.
Armadilhas comuns
Autenticação como autorização; UUID como controlo de acesso; gateway como conhecimento de todas as relações; scope de leitura como escrita.
Tópicos relacionados: Fronteiras de confiança · Autorização de APIs · Revogação e operação
A decisão precisa de corresponder ao sujeito, objeto, ação e contexto de cada pedido.
Referência: Authorization Cheat Sheet · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17