RBAC + ABAC: dois modelos complementares
RBAC
Role-Based Access Control
Controle baseado em quem você é: roles atribuídos ao usuário ou grupo definem quais ações ele pode executar. Simples de gerenciar, ideal para permissões permanentes.
ABAC
Attribute-Based Access Control
Controle baseado em contexto: políticas com condições avaliadas em tempo de execução (hora, departamento, IP). Ideal para restrições temporais ou por localização.
Decisão combinada
O PermissionsService avalia RBAC e ABAC independentemente. O acesso é concedido se qualquer um dos dois retornar allow. O resultado inclui a fonte (RBAC, ABAC, BOTH ou NONE).
RBAC — Roles e permissões
Admin Console → Identidades → Permissões → Roles.
Fluxo de configuração RBAC
Criar permissões
Defina as permissões granulares do sistema (ex: resources:create, documents:read). Representam ações específicas sobre recursos.
Criar role
Agrupe permissões relacionadas em um role (ex: "editor" agrupa resources:create, resources:read, resources:update).
Atribuir role
Atribua o role a um usuário diretamente ou a um grupo. Membros do grupo herdam o role automaticamente.
Verificação de acesso
Em cada request, o sentinel-core consulta o Keto com a tripla (user, action, resource). O Keto resolve a cadeia de tuplas e retorna allow ou deny.
Campos de um role
Identificador único no tenant. Imutável após criação.
Rótulo legível na interface.
Explica o propósito do role.
Lista de permissões granulares que este role concede. Pode ser editada após criação.
Exemplos de roles
Hierarquia de atribuição
Roles podem ser atribuídos em três níveis diferentes.
Direto (usuário ↔ role)
Role atribuído diretamente ao usuário. Independente de grupos. Bom para casos excepcionais ou usuários únicos.
tenant:acme#admin@user:uuid-joaoVia grupo (usuário → grupo → role)
Usuário herda o role por pertencer a um grupo. Escala bem — um role no grupo serve todos os membros.
group:dev#admin@role:editor
group:dev#member@user:uuid-mariaGlobal (admin-global)
Usuários com role admin-global têm acesso a múltiplos tenants para gerenciamento centralizado da plataforma.
platform:sentinel#super-admin@user:uuid-opsABAC — Políticas por atributo
Condições avaliadas em tempo de execução para controle contextual de acesso.
Estrutura de uma política ABAC
Uma política define um efeito (allow ou deny) e uma lista de condições. Todas as condições devem ser verdadeiras para o efeito ser aplicado (lógica AND).
time.hour >= 9 AND time.hour < 17
user.department in ["engineering","devops"]
user.location equals "BR"
Atributos disponíveis
Tempo
Usuário
Request
Operadores suportados
equals / not_equalsIgualdade exatain / not_inValor dentro de uma listagreater_than / less_thanComparação numérica (ideal para hora, mês)contains / not_containsString contém substringstarts_with / ends_withPrefixo ou sufixo de stringmatches_regexExpressão regularAPI de verificação de acesso
Use o endpoint do sentinel-core para verificar permissões em suas aplicações.
Verificar acesso efetivo
POST /api/policies/access/check
{
"userId": "user@empresa.com",
"permission": "documents:read",
"resource": "document:12345",
"tenantSlug": "acme-corp",
"context": {
"user.department": "engineering"
}
}
Resposta
{
"allowed": true,
"source": "RBAC",
"reason": "role:editor grants documents:read"
}
Playground de permissões
Teste em tempo real
O Admin Console inclui um Permissions Playground (em Identidades → Permissões) onde você pode testar verificações de acesso em tempo real: informe um usuário, uma permissão e um recurso para ver se o acesso seria concedido — e qual a fonte da decisão (RBAC, ABAC ou BOTH).
O playground consulta o Keto e o PermissionsService em tempo real, mas não modifica nenhum dado — é seguro para testes em produção.