Pular para o conteúdo principal

Códigos de permissão

A autorização é expressa como códigos de permissão. Todo endpoint declara os códigos que exige; quem os tem todos é autorizado, e quem não tem algum é recusado com os códigos faltantes nomeados na resposta.

Nomenclatura

Códigos seguem resource.action:

entity.read
match-profile.update
consent-record.create

O recurso é a coisa sobre a qual se age; a ação é o que se faz com ela. Ações comuns são read, create, update e delete, com ações específicas de domínio onde a operação não é CRUD comum — entity.merge, entity.match.

O catálogo é fechado

Códigos são definidos pela plataforma, não inventados por organizações. Uma organização compõe papéis a partir do catálogo; não pode criar um código que a plataforma não aplique.

É isso que mantém a autorização significativa. Um código que nada verifica seria uma permissão que não concede nada aparentando conceder algo.

Códigos novos são reconciliados em toda organização automaticamente quando a plataforma os acrescenta, então o catálogo de uma organização nunca fica atrás do software.

Famílias de recursos

FamíliaGoverna
entityRegistros, seus registros de origem, relacionamentos e linhagem de consolidação — entity.source-record.*, entity.relationship.*, entity.merge-history.*
entity-type, attribute-def, relationship-typeO modelo de dados
rdmDados de referência — tipos de lookup, valores, transcodificação, hierarquias
standardization-rule, standardizeConfiguração e execução de padronização
authOperações de autenticação, incluindo auth.impersonate
dqQualidade de dados — dq.validation-rule.*, dq.score.*
match-profile, match, potential-match, potential-overlayConfiguração, execução e revisão de comparação
relationship-resolution-rule, relationship-assertionResolução de relacionamentos
searchBusca
bulk-jobTrabalhos assíncronos
interaction, interaction-typeInterações
consent-record, consent-type, dsrConsentimento e solicitações de privacidade
auditO log de auditoria
user, role, group, permissionAdministração de identidade e papéis
abac-policy, field-masking-rulePolíticas ABAC e mascaramento
identity-provider, session, system-tokenAutenticação e credenciais de máquina
webhookEntrega de eventos
config-snapshot, tenant-ui-config, statistics, source-systemConfiguração e relatórios da organização
platformAdministração entre organizações
meO próprio perfil, caixa de entrada e notificações de quem consulta
assistantAcesso ao assistente embutido

A lista autoritativa é servida pela plataforma. Consulte-a em vez de transcrever daqui — uma lista copiada para um documento diverge.

Papéis

Um papel é um conjunto nomeado de códigos, composto por organização. Usuários têm papéis diretamente ou por grupos, e as permissões efetivas são a união de todos eles.

União, não interseção: ter dois papéis concede tudo que qualquer um concede.

A resolução é ao vivo

Permissões efetivas são resolvidas por requisição, não gravadas num token. Uma concessão ou revogação vale na requisição seguinte de quem consulta.

A desativação vale imediatamente

Dois mecanismos independentes garantem isso. Mudar a situação de um usuário invalida seu contexto de autorização em cache, então a requisição seguinte é recusada; e o identificador de cada token é verificado contra uma lista de revogação a cada requisição, então uma sessão revogada é rejeitada de imediato.

Você não precisa encurtar a validade dos tokens para tornar a desativação efetiva.

Proteções contra autoação

Um usuário não pode agir destrutivamente sobre si mesmo — desativar a própria conta, excluir-se ou remover os próprios papéis é recusado mesmo com todas as permissões.

Isso não é paternalismo. Impede que o último administrador tranque a organização para fora da própria gestão de usuários, o que é irrecuperável de dentro.

Acesso ao assistente não é acesso a dados

assistant.access concede uso do assistente embutido. Não concede nenhum acesso a dados — as outras permissões do usuário já decidiram isso, e o assistente age como o usuário.

A seguir


Última verificação no commit d3c2586b (2026-08-03)