Modelo de controlo de acesso

Esta página explica como o Access Management organiza departamentos, perfis, utilizadores e permissões, e como isso se traduz no token que cada pedido leva.

EntidadesCopy Anchor Link

Tabelas de ligação: t_role_permission (perfil ↔ permissão), t_permission_department (permissão ↔ departamento), t_department_application, t_application_role, t_application_resource, t_resource_permission e t_department_menuentry.

DepartamentosCopy Anchor Link

Os departamentos formam uma árvore: cada um aponta para o pai, sem limite de profundidade.

O departamento não dá permissões a ninguém. Define que permissões estão disponíveis para os perfis desse departamento e dos departamentos abaixo dele.

PerfisCopy Anchor Link

Cada perfil pertence a exatamente um departamento. O código do perfil é único dentro do departamento (dois departamentos podem ter um perfil tecnico). O código de um perfil filho leva o do pai como prefixo: o Técnico criado debaixo do Gestor fica gestor.tecnico.

Os perfis de um departamento também podem formar uma árvore, mas a árvore é uma regra de atribuição, não herança:

• Ao dar permissões a um perfil filho, só são aceites as que o perfil pai já tem.
• E só as que estão disponíveis no departamento do perfil ou num departamento acima.
• Nenhum perfil recebe automaticamente as permissões do pai nem dos filhos.

PermissõesCopy Anchor Link

As permissões são globais por nome. A convenção é igrp.{domínio}.{ação} (igrp.documento.ler), mas não é imposta: o nome aceita letras, números, ., _ e -.

Uma permissão chega a um perfil por três passos:

1. O backend da aplicação declara-a (@IgrpPermission) e publica-a no arranque, ligada ao recurso da aplicação — ver Sincronização.
2. Um administrador torna-a disponível num departamento.
3. O administrador dá-a a um perfil desse departamento (ou de um departamento abaixo).

Perfil ativo e permissões efetivasCopy Anchor Link

Um utilizador pode ter vários perfis, em departamentos diferentes, cada um por uma atribuição (que pode expirar). Em cada momento um é o perfil ativo.

• O JWT leva em permissions só as permissões diretas do perfil ativo.
• org é o código do departamento do perfil ativo.
• resource_access lista todos os perfis ativos do utilizador.
• Para trocar de perfil ativo: POST /api/users/me/roles/active com { roleCode, departmentCode } (o administrador usa POST /api/users/{id}/roles/active). A troca revoga as sessões do utilizador: o token seguinte já vem com as permissões do novo perfil.

Claims do JWTCopy Anchor Link

{
  "sub": "f3c1…",
  "sid": "8a2d…",
  "device_id": "c41e…",
  "selectedRole": "tecnico",
  "org": "SADM",
  "permissions": ["igrp.documento.ler", "igrp.documento.criar"],
  "resource_access": {
    "minha-app": { "roles": ["tecnico", "arquivista"] }
  },
  "is_super_admin": false,
  "email": "maria.silva@exemplo.cv",
  "exp": 1793055600,
  "iss": "https://<gateway>/igrp-access-management"
}

Verificação em cada pedidoCopy Anchor Link

Na API do Access Management, cada pedido passa por duas verificações:

Os backends dos projetos validam o JWT e decidem com @PreAuthorize sobre o permissions do token — ver o percurso em Framework › Backend › Permissões.

InvalidaçãoCopy Anchor Link

Cada alteração estrutural publica um evento. Os eventos revogam as sessões afetadas e, nalguns casos, limpam a cache de permissões no Redis:

Como as permissões vão no token, uma alteração só tem efeito com um token novo. A revogação da sessão força isso: o pedido seguinte com o sid antigo recebe 401 e a aplicação volta a autenticar o utilizador.

Cenário completoCopy Anchor Link

1. Os Serviços Administrativos (SADM) têm o perfil Técnico, com igrp.documento.ler e igrp.documento.criar. O Arquivo (ARQ), filho de SADM, tem o perfil Arquivista, com igrp.arquivo.consultar.
2. A Maria Silva tem os dois perfis atribuídos, com o Técnico ativo. O token dela leva as permissões do Técnico e org: SADM.
3. Para consultar o arquivo, troca o perfil ativo para Arquivista. As sessões são revogadas e o token novo leva igrp.arquivo.consultar e org: ARQ — e já não as permissões do Técnico.

ResumoCopy Anchor Link