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

# Habilitando o Access Manager

> Ative o Access Manager nos produtos Lerian — defina as variáveis de Auth em cada `.env` para seus serviços começarem a aplicar o controle de acesso.

[Instalar o Access Manager](/pt/platform/access-manager/installing-access-manager) não basta por si só. Para começar a aplicar o controle de acesso, você o ativa em cada produto definindo as variáveis de Auth no arquivo `.env` de **qualquer produto ou plugin da Lerian** onde quiser deixá-lo ativo.

<Note>
  Habilitar o Access Manager apenas liga a aplicação de autorização em um produto ou plugin. Dados de acesso como usuários, grupos, aplicações, providers, roles e permissões são gerenciados separadamente através do Access Manager.
</Note>

Cada produto protegido precisa habilitar a validação e apontar para o Auth. A variável de endereço não é a mesma em todos os repositórios, então use a variável esperada pelo produto que você está configurando:

<CodeGroup>
  ```text Text theme={null}
  # Maioria dos produtos e plugins
  PLUGIN_AUTH_ENABLED=true
  PLUGIN_AUTH_ADDRESS=http://plugin-auth:4000
  ```

  ```text Text theme={null}
  # Midaz Ledger e Pix Direct JD
  PLUGIN_AUTH_ENABLED=true
  PLUGIN_AUTH_HOST=http://plugin-auth:4000
  ```
</CodeGroup>

Para deployments BYOC multi-tenant, habilite o modo multi-tenant no Access Manager e em cada produto protegido que participa do isolamento de tenant:

<CodeGroup>
  ```text Text theme={null}
  # MULTI-TENANT CONFIG
  MULTI_TENANT_ENABLED=true
  ```
</CodeGroup>

Em deployments single-tenant, o Access Manager usa a organização padrão configurada. Em deployments multi-tenant, o escopo do tenant é resolvido a partir do token confiável e do contexto da aplicação.

<Danger>
  Uma vez que o **Access Manager** esteja habilitado, as requisições a APIs protegidas devem incluir um header `Authorization` com um **Bearer access token** válido.

  Sem esse header, requisições protegidas serão rejeitadas, mesmo para endpoints que antes eram acessíveis sem autenticação.

  [**Aprenda como gerar e usar access tokens.**](/pt/platform/access-manager/using-access-manager)
</Danger>

## Onde atualizar

***

Você encontrará os arquivos `.env` relevantes nestas localizações:

* **Midaz**
  * `/midaz/components/ledger` usa `PLUGIN_AUTH_HOST`
  * `/midaz/components/crm` usa `PLUGIN_AUTH_ADDRESS`
* **Outros produtos e plugins**
  * Use o arquivo `.env` na raiz do produto ou plugin, ou no diretório do componente quando o repositório for dividido em componentes.
  * Reporter, Tracer, Flowker, CRM, Fees Engine, Bank Transfer, Pix Indirect BTG e Fetcher usam `PLUGIN_AUTH_ADDRESS`.
  * Pix Direct JD usa `PLUGIN_AUTH_HOST`.

<Tip>
  Não consegue ver os arquivos? Ajuste as configurações do seu sistema para mostrar arquivos ocultos. Arquivos `.env` geralmente ficam ocultos por padrão.
</Tip>

## Reconstruir após as alterações

***

Após atualizar o ambiente, reconstrua suas imagens Docker para aplicar as alterações:

<Steps>
  <Step>
    No seu terminal, vá para a raiz do seu projeto.
  </Step>

  <Step>
    Se o Docker estiver rodando, pare-o:

    <CodeGroup>
      ```bash Bash theme={null}
      make down
      ```
    </CodeGroup>
  </Step>

  <Step>
    Então reconstrua tudo:

    <CodeGroup>
      ```bash Bash theme={null}
      make rebuild-up
      ```
    </CodeGroup>
  </Step>
</Steps>

## Ciclo de vida do deployment

***

A configuração do Access Manager tem duas fases:

* **Bootstrap** popula um novo ambiente com as organizações, roles, groups, aplicações e permission sets básicos exigidos pela plataforma.
* **Operação** começa quando o ambiente está em execução. A partir daí, gerencie o acesso pelas APIs do Identity ou pelo Lerian Console.

Use as APIs operacionais para acesso de usuários, atribuição de grupos, credenciais de aplicação, providers e MFA. Não altere um ambiente em execução editando arquivos de seed do bootstrap.

<Warning>
  Os dados de seed do bootstrap são aplicados apenas durante a configuração inicial do ambiente. Mudanças em resources, actions, roles, groups, aplicações ou permission sets nativos em um ambiente existente devem ser entregues por atualizações controladas da plataforma, como migrations ou um reconciler idempotente.
</Warning>