Это похоже на то, что вы рассматриваете ACL как аспект, который можно использовать повторно на разных наборах данных, и если это предположение, я не уверен, что он держится.
Последний раз, когда я построил большую систему, включающую разрешения, модель была чем-то вроде этого.
- У вас есть несколько пользователей
- У вас есть несколько ресурсов
- У вас есть целый ряд операций, которые могут выполняться на ресурсах.
- Вы можете определить роли, которые определяют различные разрешений наборов (набор операций)
- У вас есть целый ряд проектов
- Ресурсы контекстных проектов (они имеют ProjectID)
- Пользователю присваиваются ноль или более роли в каждом проекте (сопоставления)
- Доступ пользователя к ресурсу зависит от ролей пользователя в проекте, который владеет ресурсом (это можно было бы изменить во время выполнения).
Если пользователь U хочет удалить ресурс A, вам необходимо выяснить, к какому принадлежит ресурс проекта A, и если эффективный набор разрешений U (объединение всех ролей U может иметь в проекте) содержит «Удалить ресурс» привилегирован.
При написании запросов SQL/JPA вы должны быть очень осторожны, поскольку вы никогда не сможете доверять клиенту. Это означает, что вы не можете POST projectId и resourceId, вам всегда нужно начинать с resourceId, видеть, к какому проекту он принадлежит, а затем проверить, разрешена ли операция.
Если у вас есть функция «Просмотр всех», позволяющая пользователю просматривать все ресурсы по проектам, а пользователь может видеть ресурсы в 3 из 5 проектов, вам нужно спросить свою модель безопасности о списке проектов, в которых пользователь имеет привилегии View Resource, а затем добавьте эти идентификаторы проекта в запрос для загрузки данных. ProjectIds необходимо включить в запрос, точно так же как параметры сортировки и разбивки на страницы. Обычно вам понадобятся два запроса, так как вам также нужен запрос на подсчет для вычисления общего количества страниц.
По моему опыту, модель данных и ACL полностью переплетаются. Если вы хотите сделать реализацию ACL независимой от модели данных, я боюсь, что вы либо закончите с неэффективной системой, которая должна загружать слишком много данных, а затем отфильтровывать ресурсы на основе разрешений впоследствии.Или вы получите сложную систему, потому что вам нужен общий способ переноса логики ACL в запросы загрузки ресурсов (и в описанной системе они не так-то просто начать).
Могут быть более простые системы, чем описанные мной, где будет реализована общая реализация ACL, но не на предприятиях, которые я реализовал за последние 8 лет.
Почему вы предпочли бы это сделать в каждом конкретном случае. Обычно вы используете логику соответствия, чтобы указать, какие конечные точки требуют аутентификации и потенциально, какую авторизацию (роль) должен иметь пользователь. Вы также можете использовать @PreAuthorize ("hasRole ('ROLE_USER')"), в обоих случаях ключ должен создать правильный список GrantedAuthority, когда вы создаете аутентификацию. –
Я понимаю, но у меня есть моя собственная система авторизации (авторизации и авторизации), которую я пытаюсь подключить с помощью Spring. И для этого мне нужно найти подходящее место для ввода моего кода. Мне удалось найти нужное место для авторизационной части ('PreInvocationAuthorizationAdvice.before'), и теперь я ищу подходящее место для аутентификации. – Mehran
ACL - это непростая вещь для реализации, является ли она частью базы данных (она охватывает видимость данных) или внешняя? В системах CMS, где видимость данных связана с пользователем, вы не можете использовать декларативную безопасность в одиночку, вам обычно нужно найти разрешения для пользователей и включить некоторые идентификаторы в запросы, чтобы убедиться, что вы загружаете только то, что пользователь может видеть. –