Menu Permissions

We begin by introducing a Spring Boot example featuring a menu system. This example leverages jCasbin to manage menu permissions. Ultimately, it aims to abstract a middleware, specifically for menu permissions, which could be extended to other languages supported by Casbin, such as Go and Python.

1. Configuration Files

You need to set up role and permission management in the policy.csv file, along with the parent-child relationships between menu items. For more details, please refer to this GitHub repo.

1.1 Overview

Using policy.csv, you can flexibly configure role permissions and menu structures for fine-grained access control. This configuration file defines access permissions for different roles on various menu items, associations between users and roles, and the hierarchical relationships between menu items.

1.2 Permission Definitions (Policies)

Policy Rules: Policies are defined with a p prefix, specifying roles (sub) and their permissions (act) on menu items (obj), along with the rule's effect (eft), where allow indicates permission is granted, and deny indicates it is denied.

Examples:

p, ROLE_ROOT, SystemMenu, read, allow means the ROLE_ROOT role has read access to the SystemMenu menu item.
p, ROLE_ROOT, UserMenu, read, deny means the ROLE_ROOT role is denied read access to the UserMenu menu item.

1.3 Roles and User Associations

Role Inheritance: User-role relationships and role hierarchies are defined with a g prefix. This allows users to inherit permissions from one or multiple roles.

Examples:

g, user, ROLE_USER means the user user is assigned the ROLE_USER role.
g, ROLE_ADMIN, ROLE_USER means ROLE_ADMIN inherits permissions from ROLE_USER.

Menu Relationships: Parent-child relationships between menu items are defined with a g2 prefix, aiding in the construction of a menu's structure.

Examples:

g2, UserSubMenu_allow, UserMenu indicates UserSubMenu_allow is a submenu of UserMenu.
g2, (NULL), SystemMenu indicates SystemMenu has no submenu item, meaning it is a top-level menu item.

When managing menu permissions with jCasbin, the permission relationship between parent and child menus follows specific inheritance rules, with two important default rules:

Inheritance of Parent Menu Permissions:

If a parent menu is explicitly granted allow permission, all its submenus also default to allow permission unless specifically marked as deny. This means once a parent menu is accessible, its submenus are also accessible by default.

Handling Parent Menus Without Direct Permission Settings:

If a parent menu has no direct permission settings (neither explicitly allowed nor denied) but has at least one submenu explicitly granted allow permission, then the parent menu is implicitly considered to have allow permission. This ensures users can navigate to these submenus.

1.6 Special Permission Inheritance Rules

Regarding the inheritance of permissions between roles, especially in scenarios involving deny permissions, the following rules must be followed to ensure system security and precise control of permissions:

Distinction Between Explicit and Default Denials:

If a role, such as ROLE_ADMIN, is explicitly denied access to a menu item, such as AdminSubMenu_deny (marked as deny), then even if this role is inherited by another role (e.g., ROLE_ROOT), the inheriting role is not permitted access to the denied menu item. This ensures explicit security policies are not bypassed due to role inheritance.

Inheritance of Default Denial Permissions:

Conversely, if a role's denial of access to a menu item (e.g., UserSubMenu_deny) is default (not explicitly marked as deny, but because it was not explicitly granted allow), then when this role is inherited by another role (e.g., ROLE_ADMIN), the inheriting role may override the default deny status, allowing access to these menu items.

1.7 Example Description

policy:

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

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

The list of all menu items accessible by a given username can be identified through the findAccessibleMenus() function available in the MenuService. To check whether a specific user has the rights to access a designated menu item, the checkMenuAccess() method can be utilized. This approach ensures that menu permissions are effectively controlled, leveraging jCasbin's capabilities to manage access rights efficiently.