> ## 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 da 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. É 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.

<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.
</Warning>

## Modelo de permissão

***

O Access Manager avalia a autorização com três valores:

| Valor    | Significado                                                                                         |
| -------- | --------------------------------------------------------------------------------------------------- |
| Subject  | O usuário autenticado ou a aplicação máquina-a-máquina.                                             |
| Resource | A área protegida de um produto, como `users`, `applications`, `accounts`, `reports` ou `templates`. |
| Action   | A 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:

| 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 a rota não é melhor descrita por um método HTTP:

| Exemplo              | Significado                                     |
| -------------------- | ----------------------------------------------- |
| `transfers:create`   | Criar uma transferência do Bank Transfer.       |
| `transfers:process`  | Processar uma transferência do Bank Transfer.   |
| `system_config:read` | Ler a configuração de sistema do Bank Transfer. |
| `workflows:activate` | Ativar um workflow do Flowker.                  |

Use [Recuperar Permissões do Usuário](/pt/reference/access-manager/retrieve-user-permissions) para inspecionar os recursos e ações efetivos disponíveis para o usuário autenticado.

<Warning>
  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.
</Warning>

## 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.

<Note>
  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](/pt/multi-tenancy).
</Note>

## 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](/pt/platform/access-manager/identity-plugin). Para o lado de decisão em runtime, veja o [serviço Auth](/pt/platform/access-manager/auth-plugin). Para o fluxo do dia a dia com as APIs, veja [Usando o Access Manager](/pt/platform/access-manager/using-access-manager).