Skip to main content
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. Um produto com o cliente Auth habilitado e um endereço de Auth chama o Auth a partir do código no nível de rota. Esse código no nível de rota então deixa a requisição continuar ou a rejeita antes de o handler do produto rodar. O Identity define os dados de acesso. O Auth decide se um sujeito pode executar uma ação em um recurso. O controle de acesso no nível do produto aplica essas decisões 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 sujeito derivado das claims do token, o resource configurado para a rota e a action configurada para a rota.
  • envia essa verificação ao Auth.
  • segue com o handler do produto quando o Auth retorna uma decisão autorizada.
  • rejeita a requisição com o erro HTTP ou gRPC adequado quando o Auth nega.
  • usa as claims do token conforme a própria integração ciente de tenant do produto quando necessário.
Você configura a proteção de rotas separadamente em cada produto. Habilite o cliente Auth de cada produto e defina um endereço de Auth. Midaz, Flowker, Reporter, Lender, Streaming Hub, Pix via JD, Pix Lerian, Pix Indireto BTG e Bank Transfer leem AUTH_REQUIRED: defina-a como true para fazer as rotas protegidas recusarem com 503 se o cliente Auth estiver desabilitado ou mal configurado. Sem isso, o middleware deixa a requisição passar por padrão. No Access Manager, PLUGIN_AUTH_ENABLED configura apenas o cliente Auth do Identity. Ele não habilita o controle de acesso em outros 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 sujeito 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ões

O Access Manager avalia a decisão central de permissão com três valores: A autorização humana avalia permissões embutidas nos dados de identidade. Grupos podem organizar permissões, e usuários também podem receber permissões diretas de usuário. Para um token normal de usuário, o middleware deriva o sujeito das claims owner e sub dele. A menos que o produto configure verificação local de JWT, o middleware interpreta essas claims sem verificação de assinatura. A ida e volta de autorização até o 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 sujeito 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.

​
IP allowlist do tenant

Para o guia deste recurso voltado ao cliente, leia IP allowlist. O Identity armazena a IP allowlist de cada tenant e as superfícies onde ela se aplica. Uma lista não vazia se aplica apenas em escopos explicitamente selecionados: console para tráfego humano e api para tráfego de máquina. Sem escopo selecionado, a lista continua armazenada, mas fica inerte. Configure TRUSTED_PROXIES no Auth e em cada processo de produto listado em Requisitos de deploy (BYOC). Cada processo deve usar os CIDRs do load balancer ou do ingress que fica na frente dele. O produto resolve o IP do cliente e o envia ao Auth como clientIp. O Auth usa a própria configuração para decidir se pode confiar nesse endereço para aplicar a allowlist. A trava roda antes do cache de permissões do Auth. Tokens marcados como internos a contornam. Uma lista vazia não aplica a trava. Um token é interno quando carrega a claim isInternal com o valor true. O Caradhras 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 desvio pula apenas a trava da allowlist. O Auth ainda valida o token contra o Caradhras antes de autorizar a requisição, então um marcador interno forjado em um token inválido não dá acesso.
Se o Caradhras 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. Apenas uma consulta sem política em cache falha em modo aberto. Um TRUSTED_PROXIES não definido no Auth também falha em modo aberto e emite o sinal de proxy não confiável. O Auth nega uma requisição com IP de cliente ausente ou inutilizável quando uma lista não vazia se aplica. A exceção é uma requisição cujo par de transporte está em PLATFORM_INTERNAL_CIDRS. O Auth permite essa falha de encaminhamento interno da plataforma, e você deve monitorá-la.
Em deploys onde os serviços de plataforma chamam o Caradhras a partir de 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. Um prefixo que aceita tudo é rejeitado no boot, porque confiaria em todo chamador e tiraria toda entrada de tenant do controle de acesso. O Identity guarda essas faixas junto apenas enquanto existir uma lista do tenant, para que as verificações nativas do Caradhras liberem o tráfego de plataforma. O Auth as subtrai da política do tenant antes de aplicar.

​
Nomes de recurso e de ação

Nomes de recurso e de ação são strings exatas. Eles devem bater com os 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étodo HTTP: Alguns produtos usam ações semânticas quando um método HTTP não descreve bem a rota: Use Retrieve User Permissions para inspecionar os recursos e as ações efetivos disponíveis para o usuário autenticado.
Não derive strings de permissão dos caminhos de endpoint por convenção. Os produtos protegidos aplicam os valores de recurso e ação configurados no Access Manager, não valores inferidos da URL.

​
Fluxo da requisição

  1. Receber a requisição
    • O produto lê o bearer token do header Authorization.
    • Se o token está ausente ou malformado, o produto rejeita a requisição antes de qualquer verificação de permissão.
  2. Montar a verificação de permissão
    • O produto usa o recurso e a ação configurados para a rota.
    • Em deploys cientes de tenant, o produto aplica a própria integração de tenant configurada. Não deduza desse fluxo no nível de rota um contrato universal de autorização baseado apenas em tenantId.
  3. Perguntar ao Auth
    • O produto chama o Auth com o sujeito, o recurso e a ação. Dependendo da integração, ele também pode encaminhar o contexto de produto e de 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
    • Quando autorizado, o produto segue para o handler dele.
    • Quando negado, o produto retorna o erro HTTP ou gRPC adequado e não chama a lógica de negócio.

​
Onde isso se encaixa

Quando um produto configura o controle de acesso no nível de 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 sujeito autorizado ainda precisa da permissão certa de recurso e ação para chegar a uma operação específica. Uma IP allowlist de tenant ativa para o escopo daquela requisição ainda pode negá-la. O Auth pode servir decisões de autorização a partir do cache. No lado de gerenciamento desse quadro, veja o serviço Identity. O serviço Auth cuida do lado de decisão em runtime. Para o fluxo do dia a dia contra as APIs, veja Usando o Access Manager.