Pular para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt

Use this file to discover all available pages before exploring further.

O controle de acesso no nível do produto é a integração de runtime dentro de cada produto Lerian protegido. Ele não é um terceiro serviço do Access Manager. É o código no nível da rota que chama o Auth em cada requisição recebida e ou deixa a requisição continuar ou a rejeita antes do handler do produto rodar. O Identity define os dados de acesso. O Auth decide se um subject pode executar uma ação sobre um recurso. O controle de acesso no nível do produto é onde essas decisões são de fato aplicadas ao tráfego real.

​
O que ele faz

Em cada requisição protegida, o produto:
  • lê o bearer token do header Authorization;
  • monta uma verificação de permissão com o sub (subject) do token, o resource configurado para a rota e a action configurada para a rota;
  • envia essa verificação ao Auth;
  • continua com o handler do produto quando o Auth retorna uma decisão autorizada;
  • rejeita a requisição com o erro HTTP ou gRPC apropriado quando o Auth a nega;
  • usa claims confiáveis do token, como tenantId, quando a autorização ciente de tenant é necessária.
Por exemplo, uma rota do Midaz pode proteger POST /transactions com o recurso transactions e a ação post. O Auth decide se o subject no bearer token tem essa permissão para o tenant carregado no mesmo token.
O controle de acesso no nível do produto não gerencia usuários, não emite tokens e não armazena dados de política. Ele chama o Auth e age sobre a resposta.

​
Modelo de permissão

O Access Manager avalia a autorização com três valores:
ValorSignificado
SubjectO usuário autenticado ou a aplicação máquina-a-máquina.
ResourceA área protegida de um produto, como users, applications, accounts, reports ou templates.
ActionA operação sendo requisitada, como get, post, patch, delete, read ou write.
Usuários humanos recebem permissões por meio de grupos. Cada grupo está vinculado a uma ou mais roles de produto, e cada role concede acesso a um conjunto definido de recursos e ações. Aplicações máquina-a-máquina recebem permissões por meio de sua identidade de aplicação. O Auth resolve a aplicação chamadora e a verifica contra o conjunto de permissões configurado para aquela aplicação.

​
Nomes de recursos e ações

Os nomes de recursos e ações são strings exatas. Eles precisam corresponder aos valores configurados para a rota do produto, e a rota envia esses valores configurados ao Auth. A maioria dos produtos de API usa ações no estilo de métodos HTTP:
ExemploSignificado
users:getLer usuários.
applications:postCriar aplicações máquina-a-máquina.
reports:patchAtualizar relatórios.
templates:deleteExcluir templates de relatório.
Alguns produtos usam ações semânticas quando a rota não é melhor descrita por um método HTTP:
ExemploSignificado
transfers:createCriar uma transferência do Bank Transfer.
transfers:processProcessar uma transferência do Bank Transfer.
system_config:readLer a configuração de sistema do Bank Transfer.
workflows:activateAtivar um workflow do Flowker.
Use Recuperar Permissões do Usuário para inspecionar os recursos e ações efetivos disponíveis para o usuário autenticado.
Não derive as strings de permissão dos caminhos dos endpoints por convenção. Os produtos protegidos aplicam os valores de recurso e ação configurados no Access Manager, e não valores inferidos a partir da URL.

​
Fluxo da requisição

  1. Receber a requisição
    • O produto lê o bearer token do header Authorization.
    • Se o token estiver ausente ou malformado, a requisição é rejeitada antes de qualquer verificação de permissão ser tentada.
  2. Montar a verificação de permissão
    • O produto usa o recurso e a ação configurados para a rota.
    • Em deployments cientes de tenant, o produto se apoia no claim tenantId já presente no token em vez de ler identificadores de tenant de headers ou payloads.
  3. Perguntar ao Auth
    • O produto chama o Auth com o subject, o recurso e a ação.
    • O Auth avalia a requisição contra as permissões configuradas no Access Manager e pode servir a resposta a partir do cache.
  4. Aplicar a decisão
    • Se autorizada, o produto continua para o seu handler.
    • Se negada, o produto retorna o erro HTTP ou gRPC apropriado e não invoca a lógica de negócio.
O escopo de tenant é estabelecido pelo token. Em deployments SaaS e BYOC multi-tenant, o claim tenantId é resolvido automaticamente pela plataforma em cada requisição de API, então você não precisa passar um identificador de tenant em headers ou corpos de requisição. Saiba mais sobre multi-tenancy.

​
Onde isso se encaixa

O controle de acesso no nível do produto fica entre a rede e o handler do produto. É a razão pela qual um bearer token válido é exigido em cada rota protegida depois que o Access Manager é habilitado, e a razão pela qual um subject autorizado ainda precisa da permissão de recurso-ação correta para alcançar uma operação específica. Para o lado de gerenciamento desse cenário, veja o serviço Identity. Para o lado de decisão em runtime, veja o serviço Auth. Para o fluxo do dia a dia com as APIs, veja Usando o Access Manager.