Menu Permissions

This guide demonstrates a Spring Boot application that implements menu-based access control using jCasbin. The approach shown here serves as a foundation for building menu permission middleware that can be adapted to other Casbin-supported languages like Go and Python.

1. Arquivos de Configuração

Configure role permissions and menu hierarchies in the policy.csv file. For a complete working example, see the jCasbin menu permission repository.

1.1 Visão Geral

The policy.csv file enables granular access control by defining role-based permissions for menu items, user-role assignments, and hierarchical menu structures. This configuration combines three elements: which roles can access which menu items, which users belong to which roles, and how menus relate to each other in the navigation hierarchy.

1.2 Definições de Permissões (Políticas)

Policy Rules: Each policy line starts with p and defines whether a role (sub) has permission to perform an action (act) on a menu item (obj). The effect (eft) is either allow or deny.

Exemplos:

p, ROLE_ROOT, SystemMenu, read, allow grants ROLE_ROOT read access to SystemMenu.
p, ROLE_ROOT, UserMenu, read, deny denies ROLE_ROOT read access to UserMenu.

1.3 Papéis e Associações de Usuários

Role Inheritance: Lines starting with g define user-role assignments and role inheritance chains. Users automatically inherit permissions from all their assigned roles.

Exemplos:

g, user, ROLE_USER assigns the user named user to ROLE_USER.
g, ROLE_ADMIN, ROLE_USER makes ROLE_ADMIN inherit all permissions from ROLE_USER.

Menu Relationships: Lines starting with g2 define parent-child relationships between menu items, establishing the menu structure.

Exemplos:

g2, UserSubMenu_allow, UserMenu makes UserSubMenu_allow a child of UserMenu.
g2, (NULL), SystemMenu marks SystemMenu as a top-level menu with no parent.

jCasbin applies specific inheritance rules when determining menu access based on parent-child relationships:

Herança de Permissões do Menu Pai: Se um menu pai é explicitamente concedido a permissão allow, todos os seus submenus também são padrão para a permissão allow, a menos que especificamente marcados como deny.

When a parent menu has explicit allow permission, all child menus inherit allow by default unless explicitly set to deny. Granting access to a parent menu automatically grants access to its children.

Isto garante que os usuários possam navegar para esses submenus.

When a parent menu has no explicit permission but contains at least one child menu with explicit allow permission, the parent menu is implicitly granted allow status. This ensures users can reach the accessible child menus.

Distinção Entre Negações Explícitas e Padrão: Se um papel, como `ROLE_ADMIN`, é explicitamente negado acesso a um item de menu, como `AdminSubMenu_deny` (marcado como `deny`), então mesmo que este papel seja herdado por outro papel (por exemplo, `ROLE_ROOT`), o papel herdeiro não é permitido acesso ao item de menu negado.

Role inheritance interacts with deny permissions according to these rules:

Herança de Permissões de Negação Padrão: Por outro lado, se a negação de acesso de um papel a um item de menu (por exemplo, UserSubMenu_deny) é padrão (não marcada explicitamente como deny, mas porque não foi explicitamente concedida allow), então quando este papel é herdado por outro papel (por exemplo, ROLE_ADMIN), o papel herdeiro pode substituir o status de deny padrão, permitindo acesso a esses itens de menu.

Explicit deny permissions always take precedence. When a role like ROLE_ADMIN is explicitly denied access to AdminSubMenu_deny, no role that inherits from ROLE_ADMIN (such as ROLE_ROOT) can access that menu. Explicit denials cannot be overridden through role inheritance.

NomeDoMenu

Default denials (menus that lack an explicit allow) work differently. When UserSubMenu_deny is implicitly denied to ROLE_USER simply because no allow rule exists, a role inheriting from ROLE_USER (like ROLE_ADMIN) can override this by adding its own explicit allow rule.

ROLE_ADMIN

ROLE_USER

p, ROLE_ROOT, SystemMenu, read, allow
p, ROLE_ROOT, AdminMenu, read, allow
p, ROLE_ROOT, UserMenu, read, deny
p, ROLE_ADMIN, UserMenu, read, allow
p, ROLE_ADMIN, AdminMenu, read, allow
p, ROLE_ADMIN, AdminSubMenu_deny, read, deny
p, ROLE_USER, UserSubMenu_allow, read, allow

g, user, ROLE_USER
g, admin, ROLE_ADMIN
g, root, ROLE_ROOT
g, ROLE_ADMIN, ROLE_USER

g2, UserSubMenu_allow, UserMenu
g2, UserSubMenu_deny, UserMenu
g2, UserSubSubMenu, UserSubMenu_allow
g2, AdminSubMenu_allow, AdminMenu
g2, AdminSubMenu_deny, AdminMenu
g2, (NULL), SystemMenu

✅	❌	ROLE_ADMIN	ROLE_USER
SystemMenu	✅	❌	❌
UserMenu	❌	✅	❌
UserSubMenu_allow	❌	✅	✅
UserSubSubMenu	❌	✅	✅
UserSubMenu_deny	❌	✅	❌
AdminMenu	✅	✅	❌
AdminSubMenu_allow	✅	✅	❌
AdminSubMenu_deny	✅	❌	❌

Use findAccessibleMenus() from MenuService to retrieve all menu items a user can access. To verify access to a specific menu item, call the checkMenuAccess() method. These functions provide efficient menu permission enforcement through jCasbin's access control engine.