> ## 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. # Controle de acesso no nível do produto > Entenda como os produtos Lerian protegidos aplicam as decisões do Access Manager no nível da rota, chamando o Auth antes de a lógica de negócio rodar. 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. > [!WARNING] > > 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. > [!WARNING] > > 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: | Valor | Significado | | - | - | | Sujeito | O usuário autenticado, a aplicação máquina a máquina ou o sujeito derivado `admin/-editor-role` no modo M2M legado. | | Recurso | A área protegida de um produto, como `users`, `applications`, `accounts`, `reports` ou `templates`. | | Ação | A operação solicitada, como `get`, `post`, `patch`, `delete`, `read` ou `write`. | 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/-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](https://docs.lerian.studio/pt/platform/access-manager/features/ip-allowlist/overview). 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)](https://docs.lerian.studio/pt/platform/access-manager/features/ip-allowlist/deployment.md). 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. > [!WARNING] > > 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: | Exemplo | Significado | | - | - | | `users:get` | Ler usuários. | | `applications:post` | Criar aplicações máquina a máquina. | | `reports:patch` | Atualizar relatórios. | | `templates:delete` | Excluir templates de relatório. | Alguns produtos usam ações semânticas quando um método HTTP não descreve bem a rota: | Exemplo | Significado | | - | - | | `transfers:create` | Criar uma transferência do Bank Transfer. | | `transfers:process` | Processar uma transferência do Bank Transfer. | | `workflows:activate` | Ativar um workflow do Flowker. | Use [Retrieve User Permissions](https://docs.lerian.studio/pt/reference/platform/access-manager/retrieve-user-permissions.md) para inspecionar os recursos e as ações efetivos disponíveis para o usuário autenticado. > [!WARNING] > > 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](https://docs.lerian.studio/pt/platform/access-manager/identity-plugin.md). O [serviço Auth](https://docs.lerian.studio/pt/platform/access-manager/auth-plugin.md) cuida do lado de decisão em runtime. Para o fluxo do dia a dia contra as APIs, veja [Usando o Access Manager](https://docs.lerian.studio/pt/platform/access-manager/using-access-manager.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.