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

# Caradhras no Access Manager

> Veja para que o Auth e o Identity usam o Caradhras, onde ficam os dados de identidade e quais variáveis apontam o Access Manager para ele.

O Access Manager guarda os dados de identidade dele no Caradhras. O Identity e o Auth se conectam ao mesmo backend, cada um para um trabalho diferente.

## Para que cada serviço usa

***

* **Identity** armazena no backend os usuários, grupos, applications, provedores de comunicação, vínculos entre application e provedor, e configuração de MFA.
* **Auth** fica entre os seus produtos Lerian protegidos e o Caradhras. Ele encaminha os pedidos de token ao backend e valida com ele os refresh tokens. Ele também lê as claims do token que identificam o subject e o contexto de tenant.
* **A aplicação no nível do produto** depende das claims que o Caradhras emite. Um token é interno quando carrega a claim `isInternal` com o valor `true`. O Caradhras emite essa claim apenas para applications que a plataforma provisiona como serviços internos da Lerian.

O Caradhras guarda os dados de acesso. O Identity os escreve, o Auth os lê para decidir, e cada produto protegido age conforme a decisão.

Por exemplo, o Identity cria um usuário e coloca esse usuário em um grupo de produto. O Auth então emite o access token e responde às verificações de permissão que vêm depois.

## Onde os dados ficam

***

O Caradhras persiste esses dados no banco de dados PostgreSQL que você configura para o Access Manager. O PostgreSQL sustenta o Caradhras e não o substitui.

As mudanças de schema rodam como uma etapa de migração separada, nunca quando um serviço sobe.

Os dois serviços alcançam o backend no endereço que você configura. O Helm chart do Access Manager faz o deploy do backend junto com os dois serviços.

O Valkey guarda em cache os dados de token, de permissão e relacionados a MFA, para que o Auth repita menos chamadas ao backend durante a operação normal.

## Tokens e chaves

***

Os access tokens emitidos para as applications que o Identity cria expiram depois de uma hora. As applications criadas fora do Identity têm o próprio tempo de vida.

`AUTHORIZER_JWT_CERTIFICATE` guarda uma chave pública. Um backend de identidade novo gera o próprio par de chaves na primeira subida, e essa variável diz ao Access Manager em qual chave pública confiar.

Um valor configurado mas inutilizável impede o serviço de subir.

## Configuração

***

Estas variáveis conectam o Access Manager ao Caradhras.

* `AUTHORIZER_ADDRESS` dá o endereço do backend de identidade. Fora de `development`, `staging` e `local`, use um endereço https com um certificado de uma autoridade certificadora pública. Leia [Instalando o Access Manager](https://docs.lerian.studio/pt/platform/access-manager/installing-access-manager.md).
* `AUTHORIZER_JWT_CERTIFICATE` fornece a chave pública que valida os tokens que o backend de identidade emite. Leia as [variáveis de ambiente do Access Manager](https://docs.lerian.studio/pt/platform/access-manager/access-manager-environment-variables.md).
* `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` fixa o SSO pré-login em uma organização do Caradhras. Leia [Serviço Identity](https://docs.lerian.studio/pt/platform/access-manager/identity-plugin.md).
* `PLATFORM_INTERNAL_CIDRS` declara as redes a partir das quais os serviços da plataforma chamam o Caradhras. O Caradhras lê o próprio `PLATFORM_INTERNAL_CIDRS`. Defina nele o mesmo valor. Leia [Lista de IPs permitidos do tenant](https://docs.lerian.studio/pt/platform/access-manager/product-level-enforcement.md#tenant-ip-allowlist).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.