Serviço Identity

Identity é o serviço de gerenciamento do Access Manager. É onde os administradores definem quem pode acessar os produtos Lerian: a quais grupos e roles as pessoas pertencem, quais aplicações podem 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 precisar:

• criar, atualizar, listar ou excluir usuários;
• atribuir usuários a grupos de produto ou permissões diretas;
• criar, atualizar, listar ou excluir grupos e inspecionar suas permissões;
• criar, atualizar, listar ou excluir roles customizadas com escopo de tenant e atribuir suas permissões, usuários e grupos;
• criar, listar, recuperar ou excluir aplicações máquina-a-máquina;
• criar, atualizar, listar, recuperar ou excluir provedores de comunicação;
• vincular providers a aplicações e selecionar o provider padrão;
• configurar a política de SSO e o provider OAuth ativo do tenant;
• iniciar, verificar, habilitar, desabilitar, revisar ou alterar as configurações de MFA dos usuários;
• redefinir ou atualizar senhas de usuário.

​

Usuários e grupos

---

O acesso humano é gerenciado por usuários, grupos e permissões diretas de usuário. Um grupo representa um conjunto de permissões para um produto ou área do Access Manager. Por exemplo, um usuário pode ser atribuído a um grupo viewer do Midaz para inspecionar dados do ledger sem alterá-los e 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, recuperar um usuário, atualizar informações de usuário, gerenciar atribuições de grupo e permissões diretas, excluir usuários, atualizar senhas e redefinir senhas. Os endpoints de listagem de usuários e grupos são paginados com page e limit. Em deployments multi-tenant, usuários e grupos têm escopo definido a partir do bearer token. O serviço lê a organização tenant do contexto autenticado e retorna apenas os usuários e grupos que pertencem a esse tenant. Em deployments single-tenant, os mesmos endpoints retornam o conjunto de todo o ambiente. Ao criar ou atualizar um usuário, envie os IDs de grupo retornados por Listar Grupos. A API trata o prefixo interno de organização; os clientes não devem montar manualmente valores no estilo organization/group do Casdoor.

​

Roles

O Access Manager usa níveis de role como uma convenção comum entre os produtos. As ações efetivas de cada role vêm do conjunto de permissões do produto ou da aplicação. O Identity também suporta roles customizadas com escopo de 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 então usar Listar Grupos e Recuperar Detalhes do Grupo para inspecionar os grupos disponíveis no seu ambiente. Atribuições a grupos são uma forma de conceder acesso; o Identity também suporta a atribuição direta de permissões a usuários. Você pode criar roles customizadas e atribuir permissões, usuários e grupos a elas. Roles nativas do sistema são imutáveis: o Identity rejeita tentativas de criá-las, atualizá-las ou excluí-las. Use roles customizadas quando os níveis de role padrão não expressarem o modelo de acesso de que você precisa. Para o modelo de recurso-ação, os vocabulários de ações usados por cada produto e como as rotas são protegidas em tempo de execução, consulte Aplicação em nível de produto. Para o workflow de API que conecta usuários, grupos e tokens, consulte Usando o Access Manager.

​

Aplicações

---

As aplicações representam clientes máquina-a-máquina para o grant client_credentials. Use-as quando um serviço, job ou integração precisa autenticar sem um usuário humano. Uma aplicação armazena o clientId e o clientSecret usados pelo Auth durante o fluxo client_credentials. Após criar uma aplicação, a integração pode solicitar um access token ao Auth e chamar APIs Lerian protegidas de acordo com as permissões configuradas. O Identity suporta:

• listar aplicações;
• criar aplicações;
• recuperar detalhes de aplicação;
• excluir aplicações.

Por exemplo, um job de conciliação pode usar uma aplicação Bank Transfer para solicitar um token e chamar apenas os endpoints necessários para o seu workflow. O catálogo atual de permissões M2M inclui estes nomes de aplicação: Os nomes de aplicação são identificadores de produto, não rótulos de exibição na UI. O Identity aceita apenas os nomes deste catálogo ao criar ou excluir aplicações. Alguns produtos, como o Tracer, têm conjuntos de permissões M2M gerenciados pela plataforma e populados pelo seed do Access Manager, mas não fazem parte deste catálogo de criação self-service.

​

Escopo de tenant

Em deployments multi-tenant, o Identity usa o contexto autenticado como o limite de tenant para as operações de gerenciamento:

• as operações de usuário se aplicam à organização tenant do chamador;
• as listas de grupos incluem apenas os grupos de permissão disponíveis nesse tenant;
• as listas de aplicações incluem apenas as aplicações máquina-a-máquina vinculadas a esse tenant;
• as credenciais de aplicação 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 consegue listar nem alterar usuários, grupos ou aplicações de outro tenant pelas APIs públicas do Identity.

​

Provedores de comunicação

---

Os provedores de comunicação definem os serviços de entrega de email ou SMS disponíveis para as aplicações, incluindo fluxos de MFA. Eles são gerenciados separadamente das aplicações para que o mesmo provider possa ser reutilizado e controlado de forma consistente. O Identity suporta:

• listar providers;
• criar providers;
• recuperar detalhes de provider;
• atualizar providers;
• excluir providers.

O Identity também suporta vínculos entre aplicações e providers:

• listar os providers vinculados a uma aplicação;
• vincular um provider a uma aplicação;
• atualizar um vínculo de provider;
• desvincular um provider de uma aplicação;
• definir o provider padrão de uma aplicação.

Use um provider padrão quando uma aplicação tem mais de um provider vinculado e precisa de uma rota de autenticação preferencial. Para SSO, o Identity gerencia um provider OAuth ativo por tenant. Os tipos de provider suportados são Google, Microsoft, Okta e Custom. Ao configurar o primeiro provider de SSO sem disablePasswordLogin, o login local por senha permanece disponível até o primeiro login SSO bem-sucedido do tenant; depois disso, o Auth o desabilita. Defina disablePasswordLogin explicitamente para controle imediato: true desabilita o login local por senha e false o mantém habilitado. A URL de callback de SSO do Auth precisa ser uma URL absoluta e constar na allowlist de URIs de redirecionamento da aplicação; caso contrário, o relay do código de autorização falhará. Antes de salvar um provider de SSO candidato, execute a validação prévia. Ela verifica a configuração, a descoberta dos endpoints OIDC, as credenciais de cliente e a URI de redirecionamento do callback sem criar nem alterar um provider, um vínculo aplicação-provider ou uma aplicação. Uma verificação que não passa é retornada no resultado da validação; uma requisição malformada ou não autorizada retorna um erro HTTP. Para um deployment BYOC single-tenant com uma organização Casdoor fixa, defina PLUGIN_AUTH_SSO_STATIC_ORGANIZATION no Auth. O SSO antes do login passa a resolver todas as requisições nessa organização, em vez de buscar uma tag de organização domain:. Não defina essa variável quando MULTI_TENANT_ENABLED=true.

​

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 é exigido. O Identity suporta:

• iniciar a configuração de MFA;
• verificar um passcode de MFA durante a configuração;
• habilitar o MFA após a verificação;
• desabilitar o MFA;
• recuperar o status atual do MFA;
• definir o método de MFA preferencial.

O MFA pode usar métodos suportados como aplicativo autenticador, e-mail ou SMS, dependendo da configuração do ambiente e dos dados de perfil do usuário disponíveis. As operações padrão de configuração e gerenciamento de MFA são de autoatendimento: o subject do token do chamador precisa corresponder ao usuário alvo. Operações administrativas de MFA são separadas e se aplicam apenas aos métodos que essas operações suportam.

​

Arquitetura e fluxo de identidade

---

1. Requisição de gerenciamento
   • 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 deployment precisar recusar requisições de gerenciamento se esse cliente estiver indisponível ou mal configurado.
2. Processamento da requisição
   • O Identity valida o payload e aplica a operação solicitada.
   • O serviço atualiza usuários, grupos, roles, aplicações, providers, vínculos de provider, configuração de SSO ou MFA no sistema de identidade configurado.
3. Uso em tempo de execução
   • O Auth lê os dados de identidade resultantes durante os fluxos de token, permissão e MFA.
   • Os produtos Lerian protegidos dependem das decisões do Auth antes de processar operações de produto.

​

Visão geral da API

---

O Identity expõe APIs para:

• usuários;
• grupos;
• roles customizadas e suas atribuições;
• aplicações;
• providers;
• vínculos entre aplicações e providers;
• política de SSO e configuração de providers OAuth;
• configuração e gerenciamento de MFA;
• configuração de allowlist de IP do tenant;
• gerenciamento de perfil e telefone de autoatendimento;
• fluxos de redefinição e atualização de senha.

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