Pular para o conteúdo principal
Identity é um microsserviço baseado em Kubernetes que gerencia usuários, credenciais e controle de acesso em sistemas distribuídos. Ele fornece um serviço centralizado de autenticação e autorização, oferecendo uma API padronizada que se integra perfeitamente com outros serviços.

Principais funcionalidades

  • Gerenciamento de Usuários – Criar, atualizar e excluir contas de usuário.
  • Controle de Acesso Baseado em Papéis (RBAC) – Atribuir papéis predefinidos com permissões granulares.
  • Associação de Grupos – Gerenciar membros de usuários entre aplicações.
  • Autenticação OAuth2 – Fluxos de autenticação seguros usando tokens JWT.
  • Otimização de Performance – Usa cache em memória para tratamento rápido de consultas.
  • Observabilidade – Integrado com OpenTelemetry para logging e tracing.

Grupos de papéis e permissões


O acesso de usuários no ecossistema Lerian é controlado por grupos de papéis, definidos por aplicação (como Midaz, Fee Engine, CRM e outros). Cada papel determina o que os usuários podem ver ou fazer dentro de uma aplicação específica. Os papéis estão vinculados a conjuntos de permissões, que são combinações predefinidas de ações e recursos. Esses conjuntos de permissões são gerenciados centralmente e não podem ser personalizados.

Níveis de papel

Cada usuário recebe um dos seguintes papéis:
  • Admin – Acesso total a todos os recursos e ações em nível de sistema.
  • Editor – Pode criar, atualizar e excluir recursos.
  • Contributor – Pode criar e atualizar recursos, mas não pode excluir.
  • Viewer – Acesso somente leitura; pode visualizar dados mas não pode fazer alterações.
Os papéis são definidos por aplicação. Um usuário pode ter papéis diferentes em aplicações diferentes. Por exemplo, Editor no Midaz, Viewer no CRM e sem papel no Fee Engine.
Veja o que isso significa na prática:
PapelMétodos Permitidos
AdminControle total
EditorGET, POST, PATCH, DELETE
ContributorGET, POST, PATCH
ViewerGET, HEAD
Se um usuário não tem papel atribuído em uma determinada aplicação, ele não terá acesso a ela, nem mesmo somente leitura.

Conjuntos de permissões por aplicação

Por trás de cada papel há um conjunto de permissões que especifica quais recursos o usuário pode acessar e quais ações pode executar. Esses conjuntos são definidos no arquivo init/casdoor/init_data.json. Expanda a seção a seguir para ver a lista completa: Tabela de permissões
NomeNome de ExibiçãoRecursosAções
plugin-identity-editor-permissionPlugin Identity Editor Permissionapplications, groups, users, update-password, reset-passwordget, post, patch, delete
plugin-identity-default-permissionPlugin Identity Default Permissionupdate-passwordpatch
midaz-editor-permissionMidaz Editor Permissionaccounts, organizations, ledgers, assets, asset-rates, portfolios, segments, balances, transactions, operationsget, post, patch, delete, head
midaz-contributor-permissionMidaz Contributor Permissionaccounts, organizations, ledgers, assets, asset-rates, portfolios, segments, balances, transactions, operationsget, post, patch, head
midaz-viewer-permissionMidaz Viewer Permissionaccounts, organizations, ledgers, assets, asset-rates, portfolios, segments, balances, transactions, operationsget, head
routing-editor-permissionPlugin Routing Editor Permissionaccount-types, transaction-routes, operation-routesget, post, patch, delete
routing-contributor-permissionPlugin Routing Contributor Permissionaccount-types, transaction-routes, operation-routesget, post, patch
routing-viewer-permissionPlugin Routing Viewer Permissionaccount-types, transaction-routes, operation-routesget
plugin-fees-editor-permissionPlugin Fees Editor Permissionpackages, fees, estimatespost, get, patch, delete
plugin-fees-contributor-permissionPlugin Fees Contributor Permissionpackages, fees, estimatespost, get, patch
plugin-fees-viewer-permissionPlugin Fees Viewer Permissionpackages, fees, estimatesget
plugin-crm-editor-permissionPlugin CRM Editor Permissionholders, aliasespost, get, patch, delete
plugin-crm-contributor-permissionPlugin CRM Contributor Permissionholders, aliasespost, get, patch
plugin-crm-viewer-permissionPlugin CRM Viewer Permissionholders, aliasesget
reporter-viewer-permissionReporter Viewer Permissiontemplates, reports, data-sourceget
reporter-contributor-permissionReporter Contributor Permissiontemplates, reports, data-sourceget, post, patch
reporter-editor-permissionReporter Editor Permissiontemplates, reports, data-sourceget, post, patch, delete

Como as permissões são estruturadas

Todos os conjuntos de permissões seguem a mesma lógica:
PapelMétodos Típicos
ViewerGET, HEAD
ContributorGET, POST, PATCH, HEAD
EditorGET, POST, PATCH, DELETE, HEAD
Essa estrutura consistente facilita entender o acesso em diferentes plugins.

Recursos por plugin

Aqui está uma referência rápida dos recursos que cada plugin gerencia:
PluginRecursos
Access Managerapplications, groups, users, update-password, reset-password
Midazaccounts, organizations, ledgers, assets, asset-rates, portfolios, segments, balances, transactions, operations, account-types, transaction-routes, operation-routes
Feespackages, fees, estimates
CRMholders, aliases
Reportertemplates, reports, data-source

Arquitetura e fluxo de identidade


O Identity segue um padrão de arquitetura limpa com o seguinte fluxo de requisição:

Fluxo de requisição

  1. Entrada de requisição HTTP
    • Os endpoints de API processam requisições recebidas.
    • Middleware trata CORS, logging e telemetria.
    • Middleware de autorização aplica políticas de acesso.
  2. Processamento de requisição
    • Handlers validam entrada e extraem parâmetros.
    • A camada de serviço executa a lógica de negócio.
    • A camada de adapter traduz chamadas de serviço para o sistema IAM externo.
  3. Fluxo de autenticação
    • Aplicações cliente autenticam usando OAuth2.
    • Tokens JWT são validados com certificados embutidos.
    • Permissões são aplicadas com base nas definições de papel.
  4. Fluxo de resposta
    • Dados são transformados em modelos de resposta da API.
    • Respostas HTTP padronizadas garantem consistência.
    • Logging e telemetria rastreiam o ciclo de vida da requisição.

Dependências externas

  • Armazenamento primário – Sistema centralizado de gerenciamento de identidade.
  • Cache – Otimizado com armazenamento de dados em memória.
  • Tracing e monitoramento – Integrado com OpenTelemetry.
  • Deploy – Kubernetes para gerenciamento de infraestrutura.

Visão geral da API


O Identity fornece gerenciamento centralizado de identidade e acesso para aplicações distribuídas. As APIs suportam:
  • Gerenciamento de contas de usuário e autenticação.
  • Controle de acesso baseado em papéis e aplicação de permissões.
  • Operações de identidade de grupos e aplicações.
O acesso é protegido por controles rígidos de permissão. Para detalhes técnicos, consulte a documentação da API do Identity.

Armazenamento de dados e modelagem


O Identity não armazena dados por conta própria — ele se conecta com sistemas externos para gerenciar identidade e cache.

Armazenamento primário

O serviço depende de um sistema externo de gerenciamento de identidade como seu armazenamento principal de dados. Ele gerencia entidades-chave como usuários, grupos e aplicações:
  • Entidade de usuário
    • Propriedades-chave: ID, nome, sobrenome, username, email, senha com hash e membros de grupos.
    • Mapeamento: Corresponde diretamente a objetos de usuário no sistema de identidade.
    • Operações: Suporta ações de criar, ler, atualizar e excluir via API.
  • Entidade de grupo
    • Propriedades-chave: ID, nome, nome de exibição, data de criação e usuários associados.
    • Mapeamento: Corresponde diretamente a objetos de grupo no sistema de identidade.
    • Operações: Operações de leitura disponíveis através da API.
  • Entidade de aplicação
    • Propriedades-chave: ID, nome, descrição, credenciais de cliente e data de criação.
    • Mapeamento: Corresponde diretamente a objetos de aplicação no sistema de identidade.
    • Operações: Suporta ações de criar, ler e excluir via API.

Armazenamento secundário

Um banco de dados baseado em documentos é integrado para suportar necessidades adicionais de persistência de dados.

Cache

Uma camada de cache é usada para melhorar a performance, gerenciando dados temporários de forma eficiente. Conexões e consumidores de cache são tratados programaticamente dentro do Identity.

Deploy e operações


  • Escalabilidade e confiabilidade – Gerenciadas através do Kubernetes.
  • Observabilidade – Integrado com OpenTelemetry.
  • Segurança – Alinhado com as melhores práticas da indústria para autenticação e autorização.
O Identity garante autenticação segura e eficiente em aplicações distribuídas, simplificando o gerenciamento de identidade com um design robusto e escalável.