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, Matcher, Reporter, Streaming Hub, Pix Lerian e Pix Indireto BTG 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, 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. No Auth, inclua também as redes a partir das quais os produtos chamam o Auth. O produto resolve o IP do cliente e o envia ao Auth como clientIp. 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 que a instituição usa 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. 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 permite uma requisição sem IP de cliente vinda de quem chama de dentro de TRUSTED_PROXIES ou PLATFORM_INTERNAL_CIDRS do próprio Auth. O Auth também permite uma requisição de produto de quem chama com um endereço não público fora de ambas. O Auth conta os dois casos em métricas, e você deve monitorá-los.
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, no Auth e no Caradhras 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 Caradhras aceita os chamadores da plataforma a partir da própria cópia do valor. O Auth as subtrai da política do tenant antes de aplicar.

​
Nomes de recurso e de ação

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.