Menu Permissions

Nous commençons par introduire un exemple Spring Boot présentant un système de menu. Cet exemple utilise jCasbin pour gérer les permissions de menu. En fin de compte, il vise à abstraire un middleware, spécifiquement pour les permissions de menu, qui pourrait être étendu à d'autres langages pris en charge par Casbin, tels que Go et Python.

1. Fichiers de configuration

Vous devez configurer la gestion des rôles et des permissions dans le fichier policy.csv, ainsi que les relations parent-enfant entre les éléments de menu. Pour plus de détails, veuillez vous référer à ce dépôt GitHub.

1.1 Vue d'ensemble

En utilisant policy.csv, vous pouvez configurer de manière flexible les permissions de rôle et les structures de menu pour un contrôle d'accès à grain fin. Ce fichier de configuration définit les permissions d'accès pour différents rôles sur divers éléments de menu, les associations entre utilisateurs et rôles, et les relations hiérarchiques entre les éléments de menu.

1.2 Définitions des permissions (Politiques)

Règles de politique : Les politiques sont définies avec un préfixe p, spécifiant les rôles (sub) et leurs permissions (act) sur les éléments de menu (obj), ainsi que l'effet de la règle (eft), où allow indique que la permission est accordée, et deny indique qu'elle est refusée.

Exemples :

p, ROLE_ROOT, SystemMenu, read, allow signifie que le rôle ROLE_ROOT a un accès en lecture à l'élément de menu SystemMenu.
p, ROLE_ROOT, UserMenu, read, deny signifie que le rôle ROLE_ROOT est refusé l'accès en lecture à l'élément de menu UserMenu.

1.3 Rôles et associations d'utilisateurs

Héritage de rôle : Les relations utilisateur-rôle et les hiérarchies de rôles sont définies avec un préfixe g. Cela permet aux utilisateurs d'hériter des permissions d'un ou de plusieurs rôles.

Exemples :

g, user, ROLE_USER signifie que l'utilisateur user est assigné le rôle ROLE_USER.
g, ROLE_ADMIN, ROLE_USER signifie que ROLE_ADMIN hérite des permissions de ROLE_USER.

Relations de menu : Les relations parent-enfant entre les éléments de menu sont définies avec un préfixe g2, aidant à la construction de la structure d'un menu.

Exemples :

g2, UserSubMenu_allow, UserMenu indique que UserSubMenu_allow est un sous-menu de UserMenu.
g2, (NULL), SystemMenu indique que SystemMenu n'a pas de sous-menu, ce qui signifie qu'il s'agit d'un élément de menu de niveau supérieur.

Lors de la gestion des permissions de menu avec jCasbin, la relation de permission entre les menus parent et enfant suit des règles d'héritage spécifiques, avec deux règles par défaut importantes :

Héritage des permissions de menu parent :

Si un menu parent est explicitement accordé la permission allow, tous ses sous-menus sont également par défaut sur la permission allow à moins qu'ils ne soient spécifiquement marqués comme deny. Cela signifie qu'une fois qu'un menu parent est accessible, ses sous-menus sont également accessibles par défaut.

Gestion des menus parents sans paramètres de permission directs:

Si un menu parent n'a pas de paramètres de permission directs (ni explicitement autorisés ni refusés) mais a au moins un sous-menu explicitement accordé la permission allow, alors le menu parent est implicitement considéré comme ayant la permission allow. Cela garantit que les utilisateurs peuvent naviguer vers ces sous-menus.

1.6 Règles spéciales d'héritage des permissions

Concernant l'héritage des permissions entre les rôles, surtout dans les scénarios impliquant des permissions deny, les règles suivantes doivent être suivies pour assurer la sécurité du système et un contrôle précis des permissions :

Distinction entre les refus explicites et par défaut:

Si un rôle, comme ROLE_ADMIN, est explicitement refusé l'accès à un élément de menu, comme AdminSubMenu_deny (marqué comme deny), alors même si ce rôle est hérité par un autre rôle (par exemple, ROLE_ROOT), le rôle héritier n'est pas autorisé à accéder à l'élément de menu refusé. Cela garantit que les politiques de sécurité explicites ne sont pas contournées en raison de l'héritage des rôles.

Héritage des permissions de refus par défaut:

Inversement, si le refus d'un rôle d'accéder à un élément de menu (par exemple, UserSubMenu_deny) est par défaut (non explicitement marqué comme deny, mais parce qu'il n'a pas été explicitement accordé allow), alors lorsque ce rôle est hérité par un autre rôle (par exemple, ROLE_ADMIN), le rôle héritier peut outrepasser le statut deny par défaut, permettant l'accès à ces éléments de menu.

1.7 Description de l'exemple

politique:

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

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

La liste de tous les éléments de menu accessibles par un nom d'utilisateur donné peut être identifiée grâce à la fonction findAccessibleMenus() disponible dans le MenuService. Pour vérifier si un utilisateur spécifique a le droit d'accéder à un élément de menu désigné, la méthode checkMenuAccess() peut être utilisée. Cette approche garantit que les permissions de menu sont efficacement contrôlées, en exploitant les capacités de jCasbin pour gérer efficacement les droits d'accès.