Skip to main content
Esta funcionalidade está disponível apenas em Staging para testes e ainda não está disponível em Produção.
Um parceiro é um dos seus próprios clientes que chama a sua plataforma Lerian pelos sistemas dele. O Access Manager permite dar a cada parceiro credenciais próprias. Você decide o que o parceiro pode fazer, em qual parte dos seus dados, de quais endereços de rede e por quanto tempo. Pense em um prédio com muitas salas. Você é o dono e tem todas as chaves. Um parceiro recebe um crachá que abre só as portas que você escolhe, funciona só no horário que você define e para de funcionar no momento em que você o cancela.

​
Por que segregar o acesso

Quando vários clientes chamam a sua plataforma, uma credencial compartilhada dá a cada um deles o acesso de todos. Os parceiros trocam isso por um conjunto de limites para cada cliente:
  • Menor privilégio. Cada parceiro recebe só as ações e os dados de que precisa, e nada acima do que a sua própria equipe pode fazer.
  • Credenciais por parceiro. Cada parceiro tem as próprias credenciais. Você pode revogar um parceiro sem mexer nos outros.
  • Revogação imediata. Suspender um parceiro, ou chegar ao fim da janela de validade dele, recusa a próxima requisição dele, mesmo com um token que ele já tem.
  • Restrição de rede. Um parceiro só pode chamar dos endereços que você lista para ele.
  • Janelas de validade. O acesso pode começar e terminar nas datas que você escolhe. Um piloto que termina em uma data não precisa de lembrete para ser desligado.
  • Responsabilidade clara. Cada requisição leva a credencial do próprio parceiro, então cada ação aponta para um único parceiro.

​
Os blocos de construção

Um tenant contém organizações, e uma organização contém ledgers. Um parceiro é um registro do tenant, e as linhas depois dele descrevem o que um parceiro recebe.

​
Como as peças se encaixam

O tenant é uma fronteira rígida. Os dados do seu tenant de staging nunca se misturam com os dados do seu tenant de produção. Dentro de um tenant, organizações e ledgers separam os seus dados de forma lógica: o Access Manager usa o escopo de cada parceiro para manter cada parceiro dentro da própria parte.
  • Tenant: Produção. O seu tenant de staging é outro, separado.
    • Organização Norte
      • Ledger N1. O Parceiro A escreve contas e transações aqui.
      • Ledger N2
        • Contas 1 e 2. O Parceiro C lê só estas duas contas.
    • Organização Sul. O Parceiro B lê a organização inteira, por 90 dias.
      • Ledger S1
      • Ledger S2
Os três parceiros ficam no mesmo tenant. Nenhum deles vê a parte de outro.

​
Exemplo: três parceiros em um tenant

A sua empresa usa um tenant por ambiente. O tenant de produção tem duas organizações do Midaz, Norte e Sul. Três dos seus clientes precisam de acesso à API.

​
Parceiro A: escreve em um ledger, de um endereço

Você também não pode dar ao Parceiro A o direito de criar ledgers. Criar um ledger atua sobre a organização inteira, que é mais amplo que um ledger. O Access Manager recusa essa alteração com IDE-1056, e o Console mostra a linha como “Fora do escopo”.

​
Parceiro B: lê uma organização inteira por 90 dias

​
Parceiro C: lê duas contas e depois é suspenso

​
Como uma requisição é decidida

As verificações abaixo rodam em cada requisição que a credencial de um parceiro envia a um produto. Elas rodam nesta ordem, e a primeira que falha para a requisição.
  1. Token. O sistema do parceiro troca o client ID e o client secret por um token de acesso e envia o token com a requisição.
  2. Parceiro. O Access Manager encontra o parceiro a quem a credencial pertence.
  3. Endereço de rede. O Access Manager compara o endereço de quem chama com a lista própria do parceiro. Um parceiro sem lista própria usa a lista do seu tenant. Uma recusa retorna 403 com AUT-0021.
  4. Estado e validade. Um parceiro suspenso, ou fora da janela de validade, é recusado com 401: AUT-1009 para suspenso, AUT-1010 para fora da janela.
  5. Permissões. O produto, o recurso e a ação precisam estar nas permissões do parceiro. Uma recusa retorna 403.
  6. Escopo. A organização, o ledger, a conta ou outro item que a requisição nomeia precisa estar dentro do escopo do parceiro. Uma recusa retorna 403.
  7. Se todas as verificações passam, o produto executa a requisição.
O produto não diz a quem chama se foram as permissões ou o escopo que recusaram a requisição. Os dois retornam o mesmo 403, então um parceiro não consegue usar as recusas para descobrir quais itens existem fora do escopo dele.

​
O que você precisa saber

  • Permissões e escopo precisam casar. Um parceiro alcança só o que os dois permitem. Permissões sem escopo em um produto com restrição obrigatória não podem ser salvas.
  • A suspensão e o fim da janela de validade valem na hora. A próxima requisição do parceiro é recusada, mesmo com um token que ele já tem. Um parceiro suspenso também não consegue tokens novos.
  • Qualquer outra alteração vale a partir da próxima requisição. Isso inclui permissões novas, um escopo mais restrito e uma nova lista de IPs permitidos.
  • Um parceiro nunca recebe mais do que o seu tenant tem. O teto é o que o papel de editor do produto tem no seu tenant. Se esse papel perder uma permissão depois, o parceiro também a perde.
  • O Access Manager não confere se os IDs do escopo existem no produto. Ele guarda os IDs que você informa. Copie-os da própria API ou do Console do produto.
  • Um produto mostrado como “ainda não está preparado para parceiros” ainda não publicou a lista de restrições dele. Você não pode dar a um parceiro acesso a esse produto até que ele publique.
  • Uma requisição que deixa de fora um item que o escopo restringe é recusada. Por exemplo, um parceiro restrito a alguns ledgers não consegue listar todos os ledgers da organização.
  • Um parceiro com aplicações não pode ser excluído. Exclua as aplicações dele antes. Para pausar um parceiro, suspenda-o. A suspensão é reversível; a exclusão não.
  • A lista de IPs permitidos própria de um parceiro substitui a lista do seu tenant. Ela não se soma a ela. Um endereço que está só na lista do seu tenant não serve para esse parceiro. A lista do parceiro vale mesmo quando a lista do seu tenant está desligada.

​
Produtos que aceitam parceiros

Cada produto declara, no manifesto de permissões dele, quais restrições aceita: por exemplo organização, ledger, conta, portfólio ou segmento. Hoje o Midaz (o ledger) e o Tracer aceitam parceiros. O Midaz exige uma organização para cada parceiro e aceita restrições opcionais em ledgers, contas, aliases de conta, ativos, portfólios, segmentos, holders e outros itens. O Tracer aceita restrições opcionais em regras, limites, validações de transação, contas, portfólios, segmentos e merchants.

​
Próximos passos

Gerenciar parceiros no Console

Crie um parceiro passo a passo, emita as credenciais dele, suspenda-o ou exclua-o.

Gerenciar parceiros pela API

As operações de parceiro, os campos, exemplos e códigos de erro.

Lista de IPs permitidos

A lista do tenant que um parceiro sem lista própria usa.

Lista de erros

Todos os códigos que o Access Manager pode retornar.