Skip to main content
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. Ele 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 por HTTP no endereço que você configura. O Auth e o Identity precisam do backend acessível antes de subirem. 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. Quando a aplicação do controle está ligada, os tokens máquina a máquina são verificados contra as chaves de assinatura atuais do emissor, renovadas automaticamente. 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

Quatro variáveis conectam o Access Manager ao Caradhras.
  • AUTHORIZER_ADDRESS dá o endereço do backend de identidade. Leia Instalando o Access Manager.
  • AUTHORIZER_JWT_CERTIFICATE fornece a chave pública que valida os tokens que o backend de identidade emite. Leia Helm chart do Access Manager.
  • PLUGIN_AUTH_SSO_STATIC_ORGANIZATION fixa o SSO pré-login em uma organização do Caradhras. Leia Serviço Identity.
  • PLATFORM_INTERNAL_CIDRS declara as redes a partir das quais os serviços da plataforma chamam o Caradhras. Quando uma lista de IPs permitidos do tenant está ativa, o Auth pode negar requisições da plataforma vindas de redes não listadas aqui. Leia Lista de IPs permitidos do tenant.