Skip to main content
O controle de acesso no nível do produto é a integração de runtime configurada dentro de cada produto Lerian protegido. Ele não é um terceiro serviço do Access Manager. Quando o cliente Auth do produto está habilitado e tem um endereço do Auth, seu código no nível da rota chama o Auth e 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

Para cada requisição em uma rota com controle de acesso configurado, o produto:
  • lê o bearer token do header Authorization;
  • monta uma verificação de permissão com o subject derivado de claims 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 do token conforme a integração de tenant do próprio produto quando necessário.
A proteção de rotas é configurada separadamente em cada produto. O cliente Auth precisa estar habilitado e ter um endereço do Auth. Defina AUTH_REQUIRED=true para que as rotas protegidas recusem com 503 se esse cliente estiver desabilitado ou mal configurado; sem isso, o middleware deixa a requisição passar por padrão. PLUGIN_AUTH_ENABLED configura apenas o cliente Auth do Identity; ele não habilita o controle de acesso em todos os produtos Lerian.
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.
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 decisão central de permissão com três valores: A autorização de usuários humanos avalia permissões incorporadas aos dados de identidade. Grupos podem organizar permissões, e usuários também podem receber permissões diretas. Para um token de usuário normal, o middleware deriva o subject de suas claims owner e sub. A menos que o produto configure a verificação local do JWT, o lib-auth analisa essas claims sem verificar a assinatura; a chamada de autorização ao Auth é a âncora de confiança. A autorização máquina-a-máquina depende de AUTH_M2M_INVERSION_ENABLED. Com o valor padrão false, o middleware deriva um subject admin/<product>-editor-role com escopo de produto para qualquer tipo de token que não seja de usuário e não consulta o sub desse token. Com true, ele usa a identidade sub do token da aplicação e rejeita tipos de token desconhecidos.

​
Allowlist de IP do tenant

O Identity armazena a allowlist de IP de cada tenant e as superfícies em que ela se aplica. Uma lista não vazia só é aplicada nos escopos selecionados explicitamente: console para tráfego humano e api para tráfego de máquina. Sem nenhum escopo selecionado, a lista é preservada, mas permanece inativa. Configure TRUSTED_PROXIES em cada processo de produto que usa o lib-auth e também no Auth. Cada processo deve usar os CIDRs do balanceador de carga ou ingress que fica à sua frente. O lib-auth do produto resolve o IP do cliente e o envia ao Auth como clientIp; o Auth usa sua própria configuração para decidir se pode confiar nesse endereço ao aplicar a allowlist. Esse controle é executado antes do cache de permissões do Auth; tokens marcados como internos o ignoram. Uma lista vazia não aplica o controle. Um token é interno quando carrega a claim isInternal com o valor true. O Casdoor emite essa claim apenas para aplicações que a plataforma provisiona como serviços internos da Lerian; a API de aplicações voltada ao cliente não pode defini-la. O bypass pula apenas o controle da allowlist: o Auth continua validando o token com o Casdoor antes de autorizar a requisição, então um marcador interno forjado em um token inválido não concede acesso.
Se o Casdoor estiver indisponível e o Auth tiver uma política em cache, o Auth serve a última política válida conhecida e ainda pode negar. Somente uma consulta sem política em cache falha em aberto (fail-open). A ausência de TRUSTED_PROXIES no Auth também falha em aberto e emite o sinal de proxy não confiável. Um IP de cliente ausente ou inutilizável é negado quando uma lista não vazia se aplica, exceto se o par de transporte da requisição estiver em PLATFORM_INTERNAL_CIDRS; essa falha de encaminhamento interno da plataforma é permitida e você deve monitorá-la.
Em deployments nos quais serviços da plataforma chamam o Casdoor por redes do cluster, configure o mesmo valor de PLATFORM_INTERNAL_CIDRS no Identity e no Auth com esses CIDRs. Cada entrada deve incluir um prefixo explícito, e um prefixo abrangente é rejeitado no boot porque confiaria em todo chamador e removeria toda entrada do tenant da aplicação. O Identity coarmazena esses intervalos somente enquanto existe uma lista do tenant para que as verificações nativas do Casdoor permitam o tráfego da plataforma; o Auth os subtrai da política do tenant antes da 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: Alguns produtos usam ações semânticas quando a rota não é melhor descrita por um método HTTP: 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 aplica sua própria integração de tenant configurada. Não infira um contrato universal de autorização baseado apenas em tenantId a partir deste fluxo no nível da rota.
  3. Perguntar ao Auth
    • O produto chama o Auth com o subject, o recurso e a ação. Conforme sua integração, ele também pode encaminhar contexto de produto e IP do cliente.
    • 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.

​
Onde isso se encaixa

Quando um produto configura o controle de acesso no nível da rota, ele fica entre a rede e o handler do produto. Com um cliente Auth habilitado e configurado, o Auth avalia a autorização antes de o handler rodar. Um subject autorizado ainda precisa da permissão de recurso-ação correta para alcançar uma operação específica e pode ser negado por uma allowlist de IP do tenant ativa para o escopo daquela requisição. O Auth pode servir decisões de autorização a partir do cache. 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.