Spring Security и архитектура наследования ролей в не плоской модели

[maiorBoltach]

Спасибо за статью.
Сам буквально месяца полтора назад прошёл путь имплементации полновесного ABAC по примерно такому же пути, только через AuthorizationManagerBeforeMethodInterceptor.

1. Есть ли какие-то проверки "на износ" под нагрузкой? В какой момент имеет смысл приделать кэширование или достаточно просто просто ходить на каждый запрос в БД?
2. С практической зрения какое решение будет более эффективное: кастомное через PreAuthorize или Spring ACL?

[kirekov]

Спасибо за фидбек.

1. Целесообразность кэширования нужно определять по результатам load testing. Если система и так справляется, то не вижу в этом смысла, так как кэширование неизбежно усложняет код и может добавить баги в плане консистентности данных. А последнее для ролей крайне важно. Например, вы забрали роль у человека, а в кэше она осталась. То есть он продолжает получать доступ, как и раньше. Вообще, как я вижу, гораздо лучше разбираться в причинах, почему запрос на выборку ролей тормозит. А их может быть много: проблема n + 1, отсутствие нужных индексов, лишние запросы, которые можно устранить, и так далее.

2. Не применял Spring ACL, так что здесь не могу что-то посоветовать. Но исходя из инфы, которую нашел на Baeldung, как я понимаю, Spring ACL также следует концепции плоской модели (если я ошибаюсь, поправьте меня). А в таком случае проблемы будут все те же самые, как и при классическом вызове метода Authentication.getAuthorities().

[dididididi]

Что по мне, вы уже затащили бизнес логику в магическую спринговую секюрность. Прекрасно, что смогли, но делать так наверно не стоит, потому что, никто кроме вас это починить не сможет.

[dimkus]

Поддерживаю.
У автора видимо подразумевается небольшое приложение с зашитыми в код возможными ролями.
Но сама изначальная идея про роли подразумевает назначение любых ролей на отдельные сегменты приложения, для доступа к которым пользователь должен содержать указанные роли исходя от бизнес задачи, т.е. должна быть разделена бизнес логика и техническая реализация, а в статье оно смешано.

[OlegZH]

Многое не понятно. Не хватает некоторых разъяснений и связок между фрагментами текста для новичка, желающего разобраться в теме. Немного даже обидно, потому что подозреваю глубокую работу, он оценить в полном объёме статью пока не могу.

Придётся задавать много дополнительных вопросов. Не возражаете?