Menu Permissions

Мы начинаем с примера Spring Boot, в котором представлена система меню. Этот пример использует jCasbin для управления разрешениями меню. В конечном итоге, он стремится абстрагировать промежуточное ПО, специально для разрешений меню, которое может быть расширено до других языков, поддерживаемых Casbin, таких как Go и Python.

1. Файлы конфигурации

Вам нужно настроить управление ролями и разрешениями в файле policy.csv, а также отношения родитель-ребенок между элементами меню. Для получения дополнительной информации, пожалуйста, обратитесь к этому репозиторию на GitHub.

1.1 Обзор

Используя policy.csv, вы можете гибко настраивать разрешения ролей и структуры меню для тонкого контроля доступа. Этот файл конфигурации определяет разрешения доступа для различных ролей к различным элементам меню, связи между пользователями и ролями, а также иерархические отношения между элементами меню.

1.2 Определения разрешений (Политики)

• Правила политики: Политики определяются с префиксом p, указывающим роли (sub) и их разрешения (act) на элементы меню (obj), а также эффект правила (eft), где allow указывает, что разрешение предоставлено, а deny указывает, что оно отклонено.

Примеры:

• p, ROLE_ROOT, SystemMenu, read, allow означает, что роль ROLE_ROOT имеет доступ на чтение к элементу меню SystemMenu.
• p, ROLE_ROOT, UserMenu, read, deny означает, что роли ROLE_ROOT отказано в доступе на чтение к элементу меню UserMenu.

1.3 Роли и связи с пользователями

• Наследование ролей: Отношения между пользователями и ролями, а также иерархии ролей определяются с префиксом g. Это позволяет пользователям наследовать разрешения от одной или нескольких ролей.

Примеры:

• g, user, ROLE_USER означает, что пользователю user назначена роль ROLE_USER.
• g, ROLE_ADMIN, ROLE_USER означает, что ROLE_ADMIN наследует разрешения от ROLE_USER.

1.4 Иерархия элементов меню

• Отношения в меню: Отношения родитель-ребенок между элементами меню определяются с префиксом g2, что помогает в построении структуры меню.

Примеры:

• g2, UserSubMenu_allow, UserMenu указывает, что UserSubMenu_allow является подменю UserMenu.
• g2, (NULL), SystemMenu указывает, что у SystemMenu нет подменю, что означает, что это элемент меню верхнего уровня.

1.5 Наследование разрешений меню и базовые правила

При управлении разрешениями меню с помощью jCasbin, отношение разрешений между родительскими и дочерними меню следует определенным правилам наследования, с двумя важными базовыми правилами:

Наследование разрешений родительского меню:

Если родительскому меню явно предоставлено разрешение allow, то все его подменю по умолчанию также получают разрешение allow, если они специально не отмечены как deny. Это означает, что как только родительское меню становится доступным, его подменю также становятся доступными по умолчанию.

Обработка родительских меню без прямых настроек разрешений:

Если у родительского меню нет прямых настроек разрешений (ни явно разрешено, ни запрещено), но у него есть хотя бы одно подменю, которому явно предоставлено разрешение allow, то родительское меню неявно считается имеющим разрешение allow. Это гарантирует, что пользователи могут переходить к этим подменю.

1.6 Особые правила наследования разрешений

Что касается наследования разрешений между ролями, особенно в сценариях, включающих разрешения deny, следующие правила должны быть соблюдены для обеспечения безопасности системы и точного контроля разрешений:

Различие между явными и по умолчанию отказами:

Если роли, такой как ROLE_ADMIN, явно отказано в доступе к пункту меню, такому как AdminSubMenu_deny (отмечен как deny), то даже если эта роль наследуется другой ролью (например, ROLE_ROOT), наследующей роли не разрешен доступ к отказанному пункту меню. Это гарантирует, что явные политики безопасности не обходятся из-за наследования ролей.

Наследование разрешений по умолчанию на отказ:

Наоборот, если отказ роли в доступе к пункту меню (например, UserSubMenu_deny) является по умолчанию (не явно отмечен как deny, но потому, что ему не было явно предоставлено allow), то когда эта роль наследуется другой ролью (например, ROLE_ADMIN), наследующая роль может переопределить статус deny по умолчанию, разрешая доступ к этим пунктам меню.

1.7 Пример описания

политика:

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	✅	❌	❌

2. Контроль разрешений меню

Список всех пунктов меню, доступных для данного имени пользователя, можно определить с помощью функции findAccessibleMenus(), доступной в MenuService. Чтобы проверить, имеет ли конкретный пользователь права на доступ к определенному пункту меню, можно использовать метод checkMenuAccess(). Этот подход гарантирует эффективный контроль разрешений меню, используя возможности jCasbin для эффективного управления правами доступа.