> ## 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 dos produtos 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. Nos produtos que leem `AUTH_REQUIRED`, defina `AUTH_REQUIRED=true` quando as requisições devem ser recusadas caso o cliente Auth esteja desabilitado ou mal configurado. [Controle de acesso no nível do produto](https://docs.lerian.studio/pt/platform/access-manager/product-level-enforcement.md) lista esses produtos. 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`. ## 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**, você talvez já rode o seu próprio provedor de identidade. O Access Manager ainda pode adicionar autorização nativa da Lerian e credenciais de aplicação onde você precisar desse controle. > [!TIP] > > Se você quiser saber mais ou avaliar o Access Manager 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](https://docs.lerian.studio/pt/reference/platform/access-manager/am-auth-apis.md) e do [Identity](https://docs.lerian.studio/pt/reference/platform/access-manager/am-identity-apis.md). * 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 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. * Login com passkey para contas de usuário. * 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: | 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](https://docs.lerian.studio/pt/platform/access-manager/installing-access-manager.md). 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. Entregue as mudanças em recursos, ações, papéis e conjuntos de permissões nativos por atualizações controladas da plataforma, como migrações ou um conciliador idempotente. Não edite os dados de seed do bootstrap para mudar o acesso em um ambiente em execução. ## Comportamento de tenant na Lerian Cloud *** Na Lerian Cloud, o tenant faz parte da identidade de quem chama. Os clientes nunca enviam a posse do tenant em payloads, parâmetros de query 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. > [!WARNING] > > 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. > [!TIP] > > [Explore a API do Access Manager](https://docs.lerian.studio/pt/reference/platform/access-manager/am-api-introduction.md). Navegue pelos endpoints de usuários, grupos, applications e permissões. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.