iGRPIGRP 3.0Documentation

Sincronização

Como o backend sincroniza permissões e o frontend sincroniza menus com o Access Management.

2. Sincronização de Permissões (Backend da Aplicação)

O pipeline @IgrpPermission → processador de anotações → AuthorizationSyncRunner está totalmente documentado no guia complementar Permissions Integration Guide. Esta secção é o resumo executivo.

2.1 Declarar permissões no código

// src/main/java/cv/igrp/demo/shared/authorization/InvoicePermissions.java
public final class InvoicePermissions {
    private InvoicePermissions() {}

    @IgrpPermission(name = "my.invoice.create", description = "Create an invoice")
    public static final String INVOICE_CREATE = "my.invoice.create";

    @IgrpPermission(name = "my.invoice.approve", description = "Approve an invoice")
    public static final String INVOICE_APPROVE = "my.invoice.approve";
}
  • A anotação possui retenção SOURCE. Está presente apenas durante a compilação.
  • O annotation processor PermissionSourceGenerator processa todas as @IgrpPermission e gera um único enum cv.igrp.framework.auth.generated.PermissionsRegistry em target/generated-sources/annotations/.
  • O valor de cada constante String deve corresponder exatamente ao valor retornado por name(). Isso permite que as IDEs ofereçam autocompletação das permissões em expressões @PreAuthorize.

2.2 Sincronizar o arranque

O AuthorizationSyncRunner, disponível no módulo cv.igrp.framework.auth:core-spring-boot, é executado durante a fase de @PostConstruct e realiza as seguintes:

  • Obtém um token M2M junto do AM, efetuando um pedido POST /oauth2/token com grant_type=client_credentials, e utilizando as credenciais configuradas em igrp.access.m2m.client-id e igrp.access.m2m.client-secret.
  • Regista a aplicação como um Resource, através de um pedido POST /api/m2m/sync/resources.
  • Envia todas as constantes do enum PermissionsRegistry.Permission como objetos PermissionDTO, através de um pedido POST /api/m2m/sync/permissions.

Comportamento da sincronização

A sincronização é idempotente e segue uma abordagem de melhor esforço (best effort):

  • As permissões já existentes são atualizadas (por exemplo, para refletir alterações na descrição).
  • As novas permissões são registadas automaticamente.
  • As permissões removidas do código não são eliminadas do AM. Esta remoção é intencional, uma vez que essas permissões podem já estar atribuídas a perfis (roles). A sua eliminação deve ser efetuada manualmente por um administrador.

Se o AM estiver indisponível, o backend da aplicação regista o erro com o nível ERROR e continua o processo de arranque. A aplicação não interrompe a inicialização, uma vez que uma falha na sincronização não deve impedir que os serviços consumidores sejam iniciados.

2.3 Aplicar em tempo de pedido

@PreAuthorize("@igrpAuthorization.checkPermission(T(Permission).MY_INVOICE_CREATE)")
@PostMapping("/api/invoices")
public InvoiceDTO create(@RequestBody InvoiceDTO dto) { … }
  • @igrpAuthorization refere-se ao bean IgrpAuthorizationService.
  • A expressão T(Permission) é resolvida através de MethodSecurityConfig.IgrpTypeLocator, que pré-regista o pacote cv.igrp.framework.auth.generated.
  • O código da permissão é recebido no JWT como uma "granted authority" em formato de String, sem qualquer prefixo. Essa autoridade é populada pelo IgrpJwtAuthenticationConverter a partir do claim permissions presente no token.

2.4 Controladores gerados pelo Studio

Nos controllers gerados pelo iGRP Studio, não edite o código-fonte para adicionar @PreAuthorize, pois essas alterações serão perdidas na próxima regeneração. Defina a permissão no separador Security do IGRP Studio. O gerador de código emitirá automaticamente a anotação @PreAuthorize correspondente durante a regeneração.

How is this guide?

Última atualização: