RBAC / ABAC через политики XACML

Я изучаю различные типы моделей управления доступом и узнал, что abac и rbac являются самыми популярными.

У меня есть базовый сценарий для одного из моих проектов, и я не мог понять, следует ли мне использовать RBAC или ABAC. Очевидно, что RBAC является подмножеством ABAC, поэтому я определенно должен выбрать ABAC, но ABAC требует некоторого опыта для написания политик в xacml. Мы используем WSO IS и APIM.

У меня есть роли администратора, владельца и участника на моем сервере идентификации (IS).

• Администратор может просматривать, удалять и обновлять пользователей.
• Владельцы могут просматривать и обновлять.
• Члены могут только просматривать.

В настоящий момент я использую глаголы HTTP для достижения желаемых результатов, то есть владельцы не могут получить доступ к запросам DELETE, а участники не могут получить доступ к PUT и DELETE.

Проблема

У меня есть панель инструментов, где я отображаю различные разделы, такие как топ-пользователи, биллинг, услуги, топ-потребители и т. д.

1. Мне нужно заполнить nav-bar на основе роли пользователя и атрибутов с сервера, например. участники не должны иметь доступа для просмотра других пользователей (Добавить, Список) в nav-bar. Элементы nav-bar зависят от роли пользователя, поэтому мы можем управлять ими через RBAC?
2. У нас есть план добавить такие роли, как операторы, маркетинг, поддержка и т. д. Означает ли это, что нам нужно создать отдельную схему базы данных для сохранения прав доступа для каждой роли?
3. На панели инструментов мне нужно скрыть / показать кнопки просмотра, обновления и удаления в пользователях, службах и т. д. Теперь члены может видеть пользователей, но не имеет разрешения на их обновление или удаление. Не может просматривать статистику, биллинг и другую личную информацию.
4. Владельцы могут видеть всех пользователей, связанных с их отделами / организацией, но администратор может видеть всех пользователей для всех отделов / организации. Здесь нам нужно использовать один и тот же api для всех потребителей, но api должен по-разному реагировать для разных ролей. Роли могут быть 10 и 100, поэтому ee не может создавать разные API для каждой роли.

Вопрос

Мы можем реализовать все эти сценарии через RBAC, но для управления nav-bar и просмотра соответствующей реализации нам нужно добавить бизнес-логику на наш сервер вместо использования WSO2-IS и WSO2-APIM. Есть ли способ управлять разрешениями просмотра, такими как кнопки и разделы скрытия / отображения, и даже использовать один и тот же API, но он должен возвращать другой результат для разных потребителей api.