Защита объекта домена с помощью Spring ACL 3

Question

У меня есть служба RESTful, которая использует внутреннюю бизнес-службу для сохранения и извлечения информации из баз данных. Webservice uri выглядит примерно так: /api/entity/{id}, к которому приложение веб-пользовательского интерфейса запрашивает с ID объекта. Здесь проблема заключается в том, что {id} может быть буквально чьим-либо идентификатором, то есть записью другого пользователя, который не должен видеть пользователь с помощью приложения. Для того, чтобы решить эту проблему, используя Spring Security, я написал SPEL, что-то вроде,

@Service 
interface EntityService { 
    @PostAuthorize("returnObject.userId==principal.id") 
    public ReturnObject get(long i); 
} 

ли вышеописанный подход правильный способ решить эту проблему? (В моих предыдущих проектах мои разработчики использовали для написания всех этих продуктов безопасности в своих бизнес-методах.) Поскольку сложность безопасности растет для сущности, скажем, администратор пользователя (который создал запись) может видеть объект, но не другие администраторы или администраторы групп могут видеть запись и т. д., этот подход тоже усложняется. Кроме того, после того, как я выкопал себе голову во многие классы библиотеки Spring-ACL, мне каким-то образом удалось настроить Spring-ACL, вызвать его оценщика разрешений, оценить метод hasPermission в SPEL с авторизацией объекта и его уникальным идентификатором загружен из базы данных.

@Service 
interface EntityService { 
    @PreAuthorize("hasPermission(#id, 'com.project.domain.ReturnObject', 'read')") 
    public ReturnObject get(long id); 
} 

Но проблема, которую я вижу при таком подходе есть, каждый раз, когда пользователь создает запись не приложение создать разрешения ACL слишком (ACL_ ENTRY) для этого объекта? Правильно ли это подходит к этой проблеме, или есть какой-то другой способ, который я не видел? Я знаю, что это не новая проблема, и кто-то там должен был решить ее уже во многих отношениях. Я хочу знать, как проблема была решена не традиционным способом в логике обслуживания или запросах, а с использованием таких фреймворков, как Spring-ACL или Apache Shiro.

Answer 1

Я не могу ответить, если Широ использует другой подход, но, как Нил прокомментировал ранее,

Spring Security не предусматривает каких-либо специальных интеграции автоматически создавать, обновлять и удалять списки контроля доступа, как часть вашего DAO или операции репозитория. Вместо этого вам нужно будет написать код [...] для отдельного домена объекты

— Spring Security Reference: Domain Object-based ACLs

с открытым кодом OACC security framework(раскрытие: Я сопровождающий и соавтор), с другой стороны, имеет концепцию create-permissions, которая позволяет точно определить, какие разрешения пользователь получит на объект после его создания.

OACC - это API, призванный помочь вам в управлении и запросе ваших разрешений и топологии безопасности программным путем.
поддерживает детализированные разрешения на вашем индивидуальных объектах домена, позволяет моделировать крупнозернистые роли, и с его понятиями доменов, разрешения наследования и олицетворением может обрабатывать почти ничего между ними.