Skip to main content
O Access Manager é como você decide quem alcança seus produtos Lerian e como os sistemas provam quem são antes de chamar uma API protegida. Este guia percorre essa configuração com as APIs. Se você prefere trabalhar de forma visual para as tarefas comuns de usuários e aplicações, use o Access Manager via Lerian Console.

​
Antes de começar

Primeiro, confirme que o cliente Auth no nível da rota de cada produto está habilitado e configurado com um endereço do Auth. As rotas protegidas então esperam um header Authorization carregando um bearer token válido.
Quando o cliente Auth de um produto está habilitado e configurado, requisições sem um bearer token válido são rejeitadas nas rotas protegidas, mesmo que o endpoint fosse acessível antes sem autenticação.
Em deployments SaaS e BYOC multi-tenant, esse token também carrega o contexto do seu tenant em claims confiáveis, então você nunca passa identificadores de tenant em payloads ou headers por conta própria. Saiba mais sobre multi-tenancy. Com as APIs do Identity, o token também é seu limite de tenant: endpoints de listagem retornam apenas os usuários, grupos e aplicações do seu tenant, e as operações de criação, atualização e exclusão permanecem dentro dele.

​
Acesso humano

Siga este fluxo quando uma pessoa precisar acessar produtos Lerian.
1

Inspecione os grupos disponíveis

Use Listar Grupos para ver os grupos disponíveis no seu ambiente.Use Recuperar detalhes do Grupo quando precisar inspecionar as permissões de um grupo específico antes de atribuí-lo.Em deployments multi-tenant, a lista é escopada ao tenant carregado pelo bearer token. Use os IDs de grupo retornados como estão ao criar ou atualizar usuários.
2

Revise a superfície de permissões

Verifique os resources e actions de cada grupo antes de atribuí-lo. As permissões do Access Manager são avaliadas como pares resource-action exatos, como reports:get, users:patch ou transfers:read.Alguns produtos usam actions no estilo de métodos HTTP, enquanto outros usam actions semânticas como read, write, create ou process. Use as permissões retornadas pela API em vez de derivar nomes de permissão a partir de paths de endpoint.
3

Crie o usuário

Use Criar um Usuário e atribua os grupos corretos durante a criação.A atribuição de grupos define o que o usuário pode acessar. Por exemplo, atribuir um grupo Midaz somente leitura permite que o usuário inspecione resources do Midaz sem alterá-los.
4

Solicite um token de usuário

Use Solicitar um Access Token com o grant type password.O access token retornado é usado como bearer token quando o usuário chama APIs protegidas.
5

Renove o token quando necessário

Use Atualizar o Access Token para trocar um refresh token válido por um novo access token.

​
Endpoints de gerenciamento de usuários

Use estes endpoints para manter o acesso humano ao longo do tempo:

​
Acesso machine-to-machine

Quando um serviço, job ou integração precisa chamar APIs Lerian sem um humano no fluxo, dê a ele sua própria aplicação.
1

Crie uma aplicação

Use Criar uma Aplicação para criar credenciais para a integração.Cada integração deve ter sua própria aplicação. Isso facilita a rotação de credenciais e a revisão de acesso. A resposta inclui o clientId e o clientSecret usados pelo Auth no fluxo client_credentials.
2

Revise ou gerencie a aplicação

Use Listar Aplicações, Recuperar detalhes da Aplicação ou Excluir Aplicação quando precisar revisar ou remover acesso machine-to-machine.O Identity esconde aplicações internas da lista. Em deployments multi-tenant, ele retorna apenas as aplicações vinculadas à organização de tenant do solicitante.
3

Solicite um token de aplicação

Use Solicitar um Access Token com o grant type client_credentials.O access token retornado é usado como bearer token para as chamadas de API da integração.

​
Catálogo atual de aplicações M2M

O catálogo atual de aplicações aceita estes nomes ao criar aplicações machine-to-machine: O Identity aceita apenas os nomes deste catálogo ao criar ou excluir aplicações máquina-a-máquina.

​
Configuração de providers

Use providers quando uma aplicação precisar de um provedor de comunicação configurado para entrega de MFA, como email ou SMS. O SSO no navegador usa uma configuração separada de provider OAuth e política de SSO; veja o serviço Identity.
  1. Crie ou revise um provider com a API de Providers.
  2. Vincule o provider à aplicação com Vincular Provider à Aplicação.
  3. Se a aplicação tiver múltiplos providers vinculados, use Definir Provider Padrão da Aplicação para selecionar o provider padrão.
Use os endpoints de application-provider quando precisar listar, atualizar, desvincular ou reordenar os vínculos de provider de uma aplicação.

​
Configuração de MFA

Use MFA para usuários que precisam de uma etapa adicional de verificação no login.
1

Inicie a configuração

Use Iniciar Configuração de MFA na própria conta do usuário autenticado e para o método de MFA selecionado.
2

Verifique a configuração

Use Verificar Passcode de MFA para confirmar o método.
3

Habilite o MFA

Use Habilitar MFA após a verificação da configuração.
4

Gerencie o MFA ao longo do tempo

Use Obter Status do MFA, Definir Método de MFA Preferido ou Desabilitar MFA conforme os requisitos de acesso do usuário mudam.
Durante o login, usuários com MFA habilitado podem precisar concluir Iniciar Desafio de MFA com o token de MFA e o método selecionado e, depois, Verificar Login com MFA, antes de receber access tokens utilizáveis. Mudanças administrativas de MFA usam operações administrativas separadas.

​
Informações do usuário e controle de sessão

Quando um usuário está ativo, alguns endpoints ajudam a inspecionar e controlar essa sessão. Recuperar Informações do Usuário retorna o perfil compatível com OIDC dele, e Recuperar Permissões do Usuário mostra os resources e actions que ele pode alcançar. Para encerrar uma sessão, chame Encerrar Sessão do Usuário com o campo de formulário obrigatório id_token_hint daquela sessão; esse endpoint não seleciona outro usuário por ID.

​
Verificações de permissão

Produtos protegidos chamam o Auth com o resource e a action que precisam aplicar. Use Validar Permissão do Usuário quando uma integração precisar verificar explicitamente uma decisão de acesso.
A resposta informa se o subject autenticado está autorizado para aquele par resource-action.

​
Regras de acesso multi-tenant

O fluxo público da API usa os mesmos endpoints em deployments single-tenant e multi-tenant, mas o comportamento multi-tenant adiciona resolução e validação de credenciais específicas do tenant:
  • Em deployments multi-tenant, Auth e Identity resolvem o tenant a partir do token confiável ou do contexto da aplicação. Para grants de senha, o Auth usa credenciais de aplicação do tenant quando disponíveis e mantém o cache de tokens ciente do tenant. O Identity também permite criar usuários novos apenas quando consegue confirmar que o domínio de e-mail corresponde ao administrador de referência do tenant.
  • Em deployments single-tenant, o Access Manager usa a organização padrão configurada.
Por isso, não adicione tenant IDs aos payloads de Identity ou Auth, a menos que um endpoint documente explicitamente esse campo. Após a autenticação, as claims do bearer token definem o escopo das chamadas normais de gerenciamento e permissão do Identity. Grants de senha e client credentials resolvem o contexto de tenant antes de existir um bearer token.