Skip to main content
O Access Manager é como você decide quem chega aos 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 visualmente nas tarefas comuns de usuário e de aplicação, use Access Manager pelo Lerian Console.

​
Antes de começar

Primeiro, confirme que o cliente Auth no nível de rota de cada produto está habilitado e configurado com um endereço de Auth. As rotas protegidas então esperam um header Authorization com um bearer token válido.
Um produto com o cliente Auth habilitado e configurado rejeita requisições sem um bearer token válido nas rotas protegidas dele. Isso vale mesmo se o endpoint antes era acessível sem autenticação.
Na Lerian Cloud, esse token também carrega o seu contexto de tenant, então você nunca passa identificadores de tenant em payloads ou headers. Com as APIs do Identity, o token também é a sua fronteira de tenant. Os endpoints de listagem retornam apenas os usuários, grupos e aplicações do seu tenant. As operações de criação, atualização e exclusão ficam dentro dela.

​
Acesso humano

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

Inspecione os grupos disponíveis

Use List Groups para ver os grupos disponíveis no seu ambiente.Use Retrieve Group Details quando você precisa inspecionar as permissões de um grupo específico antes de atribuí-lo.Na Lerian Cloud, a lista cobre apenas o seu tenant. Use os IDs de grupo retornados como estão ao criar ou atualizar usuários.
2

Revise a superfície de permissões

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

Crie o usuário

Use Create a User 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 recursos do Midaz sem alterá-los.
4

Peça um token de usuário

Use Request an Access Token com o tipo de concessão password.Use o access token retornado como bearer token quando o usuário chamar APIs protegidas.
5

Atualize o token quando precisar

Use Refresh the 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 máquina a máquina

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

Crie uma aplicação

Use Create an Application para criar credenciais para a integração.Recomenda-se que cada integração tenha a própria aplicação. Isso deixa a rotação de credenciais e a revisão de acesso mais fáceis. A resposta inclui o clientId e o clientSecret usados pelo Auth no fluxo client_credentials.
2

Revise ou gerencie a aplicação

Use List Applications, Retrieve Application Details ou Delete Application quando você precisa revisar ou remover o acesso máquina a máquina.O Identity esconde as aplicações internas da lista. Na Lerian Cloud, ele só retorna as aplicações do seu tenant.
3

Peça um token de aplicação

Use Request an Access Token com o tipo de concessão client_credentials.Use o access token retornado como bearer token nas chamadas de API da integração.

​
Catálogo de aplicações

O Identity aceita apenas nomes de aplicação do catálogo dele quando cria ou exclui aplicações máquina a máquina. List Available Applications retorna o catálogo, com o nome e o nome de exibição de cada aplicação.

​
Configuração de provedores

Use provedores quando uma aplicação precisa de um provedor de comunicação configurado para entrega de MFA, como e-mail ou SMS. O SSO de navegador usa uma configuração separada de provedor OAuth e de política de SSO. Veja o serviço Identity.
  1. Crie ou revise um provedor com a API de Provedores.
  2. Vincule o provedor à aplicação com Link Provider to Application.
  3. Se a aplicação tem vários provedores vinculados, use Set Default Application Provider para escolher o provedor padrão.
Use os endpoints de aplicação e provedor quando você precisa listar, atualizar, desvincular ou reordenar os vínculos de provedor de uma aplicação.

​
Configuração de MFA

Use MFA para usuários que precisam de um passo extra de verificação no login.
1

Comece a configuração

Use Initiate MFA Setup na conta do próprio usuário logado e no método de MFA escolhido.
2

Verifique a configuração

Use Verify MFA Passcode para confirmar o método.
3

Habilite o MFA

Use Enable MFA depois da verificação da configuração.
4

Gerencie o MFA ao longo do tempo

Use Get MFA Status, Set Preferred MFA Method ou Disable MFA conforme os requisitos de acesso do usuário mudam.
Durante o login, usuários com MFA habilitado podem precisar completar Initiate MFA Challenge com o token de MFA e o método escolhido, depois Verify MFA Login, antes de receber access tokens prontos para uso. 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. Retrieve User Information retorna o perfil compatível com OIDC dele, e Retrieve User Permissions mostra os recursos e as ações que ele alcança. Para encerrar uma sessão, chame End User Session com o campo de formulário id_token_hint daquela sessão. Esse endpoint não seleciona outro usuário por ID.

​
Verificações de permissão

Os produtos protegidos chamam o Auth com o recurso e a ação que precisam aplicar. Use Validate User Permission quando uma integração precisa verificar uma decisão de acesso explicitamente.
A resposta diz se o sujeito autenticado está autorizado para esse par de recurso e ação.

​
Regras de acesso por tenant na Lerian Cloud

Na Lerian Cloud, o Access Manager resolve o seu tenant a partir do seu token ou da sua aplicação. Para password grants e SSO, o Auth encontra o tenant a partir do endereço de email do usuário. O Identity só permite criar um usuário novo quando o domínio do email bate com o campo domain da sua organização, e recusa o usuário com IDE-0034 quando esse campo está vazio. Então não adicione IDs de tenant aos payloads do Identity ou do Auth, a menos que um endpoint documente esse campo explicitamente. Depois da autenticação, as claims do bearer token dão escopo às chamadas normais de gerenciamento e de permissão do Identity. As concessões password e client-credentials resolvem o contexto de tenant antes de um bearer token existir.