> ## 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. # O que é o Access Manager? > O Access Manager controla o acesso de pessoas e de máquinas nos produtos Lerian usando Auth, Identity e autorização no nível do produto para permissões refinadas. **Access Manager** cuida da autenticação e da autorização de cada produto Lerian. A autenticação responde quem faz uma requisição. A autorização responde o que ele tem permissão de fazer. **Access Manager** é a camada de controle de acesso da Lerian para nossos produtos e plugins. Em vez de embutir identidade e permissões em cada produto, você pode gerenciá-las em um só lugar: quem são seus usuários, quais tokens eles carregam e o que esses tokens alcançam. Quando um produto configura a aplicação no nível da rota e seu cliente Auth está habilitado, o Auth avalia o recurso e a ação solicitados antes de o handler do produto rodar. Defina `AUTH_REQUIRED=true` na integração do produto quando as requisições devem ser recusadas caso o cliente Auth dele esteja indisponível ou mal configurado. Dois serviços fazem o trabalho, e os produtos protegidos se conectam a eles no nível da rota: * **Auth** cuida do lado ativo do acesso: emitir e renovar tokens, validar sessões, verificar permissões, tratar logout e informações do usuário, e executar desafios de MFA. * **Identity** guarda os dados por trás dessas decisões: usuários, grupos, applications, provedores de comunicação, vínculos entre application e provedor, e configuração de MFA. Em uma rota protegida cujo cliente Auth do produto está habilitado e configurado, o produto envia o subject, o recurso e a ação para o Auth antes de a lógica de negócio rodar. Um operador de back-office em um grupo como `midaz-viewer-group` consegue ler os dados do Midaz, mas não consegue alterá-los. Uma integração de serviço recebe acesso conforme o subject M2M efetivo dela. Por padrão, tokens que não são de usuário usam `admin/-editor-role`. Defina `AUTH_M2M_INVERSION_ENABLED=true` para usar o `sub` do token da application. **Teste o Access Manager localmente** Rode os plugins da Lerian sem fazer deploy no Kubernetes usando nosso [repositório plugins-docker-compose](https://github.com/LerianStudio/plugins-docker-compose). Lembre que esses serviços exigem uma configuração de licença válida. As verificações de licença rodam por middleware HTTP, então valide a licença antes de habilitar os produtos protegidos. Para detalhes da licença, veja nossa [documentação de Licença](/pt/start-here/evaluate-and-deploy/lerians-license). ## Por que usar o Access Manager? *** Use o Access Manager quando você quiser controle de acesso nativo e refinado nos produtos Lerian, em vez de montar algo produto a produto. Ele permite: * gerenciar usuários humanos e os grupos de produto que definem o acesso deles * criar applications máquina a máquina para integrações de serviço * aplicar permissões até o nível do recurso e da ação, como `reports:get`, `templates:post` ou `accounts:patch` * usar um único modelo de controle de acesso em cada produto Lerian que você roda * manter as APIs dos produtos protegidas por bearer tokens e verificações no nível da rota. Como ele se encaixa na sua stack depende de como você faz o deploy: * Em **deploys SaaS**, ele é a camada de acesso da plataforma. As claims do JWT carregam o subject autenticado e o contexto de tenant em que a plataforma se apoia. * Em **deploys BYOC multi-tenant**, o contexto de tenant vem de claims confiáveis do token, nunca de payloads de requisição ou de headers arbitrários. * Em **deploys BYOC single-tenant**, você pode já rodar seu próprio provedor de identidade. Mesmo assim, o Access Manager pode acrescentar autorização nativa da Lerian e credenciais de application onde você precisar desse controle. O Access Manager está disponível como recurso opcional no **modelo Enterprise**. Se você quiser saber mais ou avaliá-lo para o seu caso de uso, [fale com o nosso time](https://lerian.studio/contact). ## Especificações técnicas *** O que vem pronto: * APIs REST para as operações do [Auth](/pt/reference/platform/access-manager/am-auth-apis) e do [Identity](/pt/reference/platform/access-manager/am-identity-apis). * Configurações do Lerian Console para a gestão visual de usuários e applications com suporte. * Aplicação da autorização no nível do produto para APIs HTTP e gRPC protegidas. * Configuração do cliente Auth por produto para a aplicação da autorização no nível da rota. * Fluxos de token OAuth2/OIDC para acesso por senha e por client credentials. * Suporte a MFA nos fluxos de autenticação de usuário. * Cache em Valkey para operações de token, de permissão e relacionadas a MFA. * RBAC alinhado aos recursos, ações, grupos e applications máquina a máquina do produto. ## Bootstrap e operação *** O Access Manager tem duas camadas de ciclo de vida distintas, e manter as duas separadas evita problemas depois: | Camada | Para que serve | | --------- | ------------------------------------------------------------------------------------------------------------------------------ | | Bootstrap | Configuração inicial do ambiente, incluindo organizações base, papéis nativos, grupos, applications e conjuntos de permissões. | | Operação | Gestão do dia a dia de usuários, atribuições de grupo, applications, provedores, MFA e revisões de acesso. | O bootstrap é o que popula um ambiente recém-criado. Depois que esse ambiente sobe, ele deixa de ser o lugar onde você faz mudanças. Para o passo a passo do operador que deixa o Auth e o Identity prontos antes de qualquer produto aplicar o controle de acesso, veja [Instalando o Access Manager](/pt/platform/access-manager/installing-access-manager). Daí em diante, gerencie o acesso pelas APIs do Identity ou pelo Lerian Console. O Console cobre o trabalho diário com usuários e applications: criar usuários, atribuir grupos, atualizar senhas e criar applications máquina a máquina. As APIs do Identity dão a superfície operacional completa, incluindo provedores, vínculos entre application e provedor, e MFA. Recursos, ações, papéis e conjuntos de permissões nativos são outra história. Entregue as mudanças neles por atualizações controladas da plataforma, como migrações ou um conciliador idempotente, e não edite os dados de seed do bootstrap para mudar o acesso em um ambiente que já está rodando. ## Comportamento multi-tenant *** Em deploys SaaS e BYOC multi-tenant, o tenant faz parte de quem é o chamador, e não é algo que ele envia. O Access Manager lê o tenant das claims confiáveis do JWT nos fluxos de usuário e da organização da application nos fluxos máquina a máquina. Os clientes nunca enviam a posse do tenant em payloads, query parameters ou headers. Isso molda o comportamento em três pontos: * **Gestão de identidade**: as APIs de usuário, grupo e application retornam apenas registros da organização do tenant do chamador. * **Autenticação**: os fluxos de senha e de refresh token mantêm o tratamento do token no escopo do tenant que o contexto do usuário carrega. * **Autorização**: as verificações de permissão avaliam apenas os grupos, papéis e permissões de application que pertencem ao tenant resolvido. Deploys single-tenant pulam tudo isso e recorrem à organização padrão configurada. Não reutilize um token de um tenant para gerenciar usuários, applications ou permissões em outro. O Access Manager limita essas operações ao contexto autenticado. ## Casos de uso *** O Access Manager serve para cenários como: * Times que querem autenticação e autorização nativas nos produtos Lerian. * Organizações sem uma solução de IAM já existente. * Times que já rodam um provedor de identidade mas ainda precisam de autorização no nível do produto. * Integrações que dependem de acesso máquina a máquina seguro. * Deploys com vários produtos que precisam de um modelo de acesso consistente para usuários, serviços e tenants. [Explore a API do Access Manager](/pt/reference/platform/access-manager/am-api-introduction). Navegue pelos endpoints de usuários, grupos, applications e permissões.