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
PermissionSourceGeneratorprocessa todas as@IgrpPermissione gera um único enumcv.igrp.framework.auth.generated.PermissionsRegistryemtarget/generated-sources/annotations/. - O valor de cada constante
Stringdeve corresponder exatamente ao valor retornado porname(). 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/tokencomgrant_type=client_credentials, e utilizando as credenciais configuradas emigrp.access.m2m.client-ideigrp.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.Permissioncomo objetosPermissionDTO, através de um pedidoPOST /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) { … }@igrpAuthorizationrefere-se ao beanIgrpAuthorizationService.- A expressão
T(Permission)é resolvida através deMethodSecurityConfig.IgrpTypeLocator, que pré-regista o pacotecv.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 peloIgrpJwtAuthenticationConvertera partir do claimpermissionspresente 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.
Última atualização:
