Serviço Identity

O Identity é o serviço de gestão do Access Manager. É onde os administradores definem quem pode acessar os produtos Lerian: a quais grupos e papéis as pessoas pertencem, quais applications podem se autenticar com credenciais máquina a máquina e quais provedores de comunicação ou OAuth estão disponíveis. O Identity não emite access tokens nem toma decisões de autorização em tempo de execução. O Auth usa os dados de identidade gerenciados aqui para autenticar subjects e avaliar permissões. Use o Identity quando você precisar:

• criar, atualizar, listar ou excluir usuários.
• atribuir usuários a grupos de produto ou a permissões diretas.
• criar, atualizar, listar ou excluir grupos e inspecionar as permissões deles.
• criar, atualizar, listar ou excluir papéis customizados com escopo de tenant e atribuir as permissões, usuários e grupos deles.
• criar, listar, obter ou excluir applications máquina a máquina.
• criar, atualizar, listar, obter ou excluir provedores de comunicação.
• vincular provedores a applications e escolher o provedor padrão.
• configurar a política de SSO do tenant e o provedor OAuth ativo.
• iniciar, verificar, habilitar, desabilitar, revisar ou mudar as configurações de MFA dos usuários.
• redefinir ou atualizar senhas de usuário.

​

Usuários e grupos

---

O Identity gerencia o acesso humano por usuários, grupos e permissões diretas de usuário. Um grupo representa um conjunto de permissões para um produto ou uma área do Access Manager. Por exemplo, você pode atribuir um usuário a um grupo viewer do Midaz para inspecionar dados do ledger sem alterá-los. Você também pode atribuir esse usuário a um grupo contributor do Reporter para criar templates de relatório. Um usuário também pode receber uma permissão direta sem pertencer a um grupo daquele produto. O Identity expõe endpoints de usuário para listar usuários, criar usuários, obter um usuário, atualizar as informações do usuário, gerenciar as atribuições de grupo e as permissões diretas, excluir usuários, atualizar senhas e redefinir senhas. Os endpoints de listagem de usuários e grupos usam page e limit para paginação. Na Lerian Cloud, o serviço retorna apenas os usuários e grupos que pertencem ao seu tenant. Quando você cria ou atualiza um usuário, envie os IDs de grupo devolvidos por Listar grupos. A API cuida do prefixo interno de organização. Recomenda-se que os clientes não montem valores organization/group manualmente.

​

Papéis

O Access Manager usa níveis de papel como convenção comum entre os produtos. As ações efetivas de cada papel vêm do conjunto de permissões do produto ou da application. O Identity também aceita papéis customizados com escopo no tenant. O Access Manager fornece o catálogo de permissões da plataforma. Você pode criar, atualizar e excluir grupos com escopo de tenant e depois usar Listar grupos e Obter detalhes do grupo para inspecionar os grupos disponíveis no seu ambiente. O Identity exclui um grupo apenas quando ele não tem membros nem subgrupos. Caso contrário, retorna 409 com o código IDE-1058 ou IDE-1059. As atribuições de grupo são uma forma de conceder acesso. O Identity também aceita a atribuição direta de permissões de usuário. Você pode criar papéis customizados e atribuir permissões, usuários e grupos a eles. Os papéis de sistema nativos são imutáveis: o Identity recusa tentativas de criá-los, atualizá-los ou excluí-los. Use papéis customizados quando os níveis de papel padrão não expressarem o modelo de acesso de que você precisa. Para o modelo de recurso e ação, os vocabulários de ação usados por cada produto e como as rotas são protegidas em tempo de execução, veja Aplicação no nível do produto. Para o fluxo de API que amarra usuários, grupos e tokens, veja Usando o Access Manager.

​

Applications

---

As applications representam clientes máquina a máquina para o grant client_credentials. Use-as quando um serviço, job ou integração precisa se autenticar sem um usuário humano. Uma application guarda o clientId e o clientSecret que o Auth usa durante o fluxo client_credentials. O Identity retorna o clientSecret apenas na resposta da requisição de criação. Se você perder o segredo, exclua a application e crie uma nova. Depois de criar uma application, a integração pode pedir um access token ao Auth e chamar as APIs Lerian protegidas conforme as permissões configuradas dela. O Identity aceita:

• listar applications.
• criar applications.
• obter os detalhes de uma application.
• excluir applications.

Por exemplo, um job de conciliação pode usar uma application do Bank Transfer para pedir um token e chamar apenas os endpoints de que o workflow dele precisa. O Identity aceita apenas nomes de application do catálogo dele quando cria ou exclui applications. Os nomes de application são identificadores de produto, como midaz ou reporter, não rótulos mostrados na interface. Listar applications disponíveis retorna o catálogo. Um produto que declara as próprias permissões deve usar uma application cujos source e target são o mesmo produto.

​

Escopo por tenant

Na Lerian Cloud, o Identity usa o contexto autenticado como limite de tenant para as operações de gestão:

• as operações de usuário valem para a organização do tenant de quem chamou.
• as listas de grupos incluem apenas os grupos de permissão disponíveis naquele tenant.
• as listas de applications incluem apenas applications máquina a máquina vinculadas àquele tenant.
• as credenciais de application criadas para uma integração pertencem ao tenant que as criou.

Isso mantém o acesso operacional local ao tenant. Um token de administrador de um tenant não pode listar nem alterar os usuários, grupos ou applications de outro tenant pelas APIs públicas do Identity.

​

Provedores de comunicação

---

Os provedores de comunicação definem os serviços de entrega disponíveis para as applications. Os provedores de e-mail podem entregar os desafios de MFA. O Identity gerencia os provedores separadamente das applications para que você possa reutilizar e controlar o mesmo provedor de forma consistente. O Identity aceita:

• listar provedores.
• criar provedores.
• obter os detalhes de um provedor.
• atualizar provedores.
• excluir provedores.

O Identity também aceita vínculos entre application e provedor:

• listar os provedores vinculados a uma application.
• vincular um provedor a uma application.
• atualizar um vínculo de provedor.
• desvincular um provedor de uma application.
• definir o provedor padrão de uma application.

Use um provedor padrão quando uma application tem mais de um provedor vinculado e precisa de um provedor preferido. Para o SSO, o Identity gerencia um provedor OAuth ativo por tenant. Os tipos de provedor aceitos são Google, AzureAD (Microsoft Entra ID), Okta e Custom. A URL de callback de SSO do Auth deve ser uma URL absoluta e aparecer na lista de URIs de redirecionamento permitidas da aplicação, ou o repasse do código de autorização falha. Antes de salvar um provedor de SSO candidato, rode a validação de preflight dele. Ela verifica a configuração, a descoberta de endpoints OIDC, as credenciais de cliente e a URI de redirecionamento de callback sem criar nem mudar um provedor, um vínculo entre application e provedor ou uma application. O resultado da validação informa a verificação que falhou. Uma requisição malformada ou não autorizada retorna um erro HTTP. Para um deploy BYOC com uma organização fixa no Caradhras, defina PLUGIN_AUTH_SSO_STATIC_ORGANIZATION no Auth. O SSO antes do login então resolve cada requisição para essa organização, em vez de procurar uma organização a partir do email do usuário.

​

Gerenciamento de MFA

---

O Identity gerencia a configuração de MFA dos usuários. O Auth usa essa configuração durante o login quando o MFA é obrigatório. O Identity aceita:

• iniciar a configuração de MFA.
• verificar um código de acesso de MFA durante a configuração.
• habilitar o MFA depois da verificação.
• desabilitar o MFA.
• obter o status atual do MFA.
• definir o método de MFA preferido.

O MFA aceita aplicativo autenticador ou e-mail. O MFA por e-mail exige um provedor de e-mail e um endereço de e-mail salvo para o usuário. As operações padrão de configuração e gestão de MFA são de autosserviço: o subject do token de quem chama deve ser o mesmo usuário alvo. As operações administrativas de MFA são separadas e valem apenas para os métodos que essas operações aceitam.

​

Arquitetura e fluxo de identidade

---

1. Pedido de gestão
   • Um administrador ou cliente autorizado chama uma API do Identity.
   • Quando o cliente Auth do Identity está habilitado e configurado, a requisição é autenticada e verificada contra as permissões do Access Manager. Defina AUTH_REQUIRED=true quando o deploy deve recusar requisições de gestão caso esse cliente esteja desabilitado ou mal configurado.
2. Processamento da requisição
   • O Identity valida o payload e aplica a operação pedida.
   • O serviço atualiza usuários, grupos, papéis, applications, provedores, vínculos de provedor, configuração de SSO ou configuração de MFA no sistema de identidade configurado.
3. Uso em tempo de execução
   • O Auth lê os dados de identidade resultantes nos fluxos de token, de permissão e de MFA.
   • Os produtos Lerian protegidos se apoiam nas decisões do Auth antes de processar as operações do produto.

​

Visão geral da API

---

O Identity expõe APIs para:

• usuários.
• grupos.
• papéis customizados e as atribuições deles.
• applications.
• provedores.
• vínculos entre application e provedor.
• política de SSO e configuração de provedor OAuth.
• configuração e gestão de MFA.
• configuração da lista de IPs permitidos do tenant.
• gestão de perfil e telefone em autosserviço.
• fluxos de redefinição e de atualização de senha.

Quando o cliente Auth dele está habilitado e configurado, o Identity protege o acesso de gestão pelas permissões do Access Manager. Para detalhes técnicos, veja a documentação das APIs do Identity.