EN
Уголок сельского джависта
Уголок сельского джависта
55 subscribers
goals
79.48 of $ 110 388 money raised
🏡 На большой семейный дом
16.56 of $ 110 388 money raised
🚘 На большую семейную машину

Access Control List (ACL) - Spring Security в деталях

Основными подходами к реализации авторизации в информационных системах являются RBAC и ABAC, однако их возможностей не всегда достаточно для обеспечения гибкого управления доступом, особенно в крупных корпоративных системах. В этом случае хорошей альтернативой может стать авторизация на основе списка правил доступа (Access Control List; ACL). Spring Security предоставляет собственную реализацию ACL, работа с которой будет продемонстрирована в этом ролике.
Да, Spring Security ACL не отличается хорошей и детальной документацией, и более того, библиотека выглядит заброшенной, а в планах разработчиков - избавиться от неё в Spring Security 7, но я всё же предлагаю ознакомиться с данной библиотекой.
Репозиторий с примерами кода: https://github.com/alex-kosarev/sandbox-spring-security-acl
00:00 Вступление
02:21 Про ACL
04:19 Настройка проекта и обзор схемы СУБД
12:30 Обзор классов Spring Security ACL
19:49 Настройка ACL
29:45 Создание ACL
36:24 Использование ACL для веб-авторизации
44:37 Использование ACL для защиты методов
46:36 Наследование правил доступа
49:16 Кумулятивные разрешения
52:27 Нестандартные разрешения (╯°□°)╯︵ ┻━┻
Мой сайт: https://alexkosarev.name/
Паблик в VK: https://vk.com/public218833461
Канал в Telegram: https://t.me/+TZCuO38vG3oqu_Jq
Стать доном: https://vk.com/donut/shurik.codes
Донаты в Tinkoff: https://www.tinkoff.ru/cf/4PEOiVCZQuS
avatar
Интересно, почему же их решили удалять?.. Из критики, нашёл лишь статью 12-го года - https://agoodcoder.blogspot.com/2012/04/alternative-to-spring-security-acl.html . Там следующие 4 пункта:
"Spring Security ACL может быть хорош, но его недостатки также очевидны:
1. Необходимо сохранять разрешения вместе с сохранением каждого бизнес-объекта
2. Необходима аннотация для каждого метода
3. Если вы решите изменить настройку прав доступа, вам придется проделать огромную работу по изменению производственных данных, а это проблематично и опасно.
4. Вероятно, у вас уже есть структура разрешений. Например, контракт создан пользователем UserA, поэтому только UserA может его изменить. Вы сохраните дублирующуюся информацию в ACL. Почему бы просто не использовать существующую структуру, которая у вас уже есть?"
avatar
Вячеслав Лапин, я лично вижу три причины:
1. Решение хоть и рабочее, но недостаточно гибкое, единственная реализация подразумевает использование реляционных СУБД в качестве источника данных.
2. Откровенно слабая документация - если попытаться всё сделать, как описано в ней, то не взлетит. Надо рыться в исходных кодах. Это сильно повышает порог вхождения, который и так достаточно высокий для ACL в целом.
3. Непопулярность. Обычно такие решения пилятся самостоятельно с интеграцией в существующую систему прав..
Критика меня порадовала)
1. Очень странная проблема) Нужно понимать, что ACL как правило реализуется в виде технической предметной области и существует самостоятельно, без реальной привязки к объектам предметной области. Можно при помощи АОП это всё автоматизировать.
2. Тоже странная проблема, аннотации, что с ACL, что без нужны.
3. Рабочий процесс, причём очевидный
4. А это демонстрирует отсутствие понимания автором ACL)

Subscription levels

🤝 Благодарный подписчик

$ 2,21 per month
Для всех тех, кому не жалко 200 рублей в месяц в знак благодарности за мои статьи и ролики. Никаких преференций это пока не даёт, просто поддержка автора.

👍 Очень благодарный подписчик

$ 5,6 per month
Для всех тех, кому не жалко 500 рублей в месяц в знак благодарности за мои статьи и ролики. Никаких преференций это пока не даёт, просто поддержка автора.

🫶 Ну очень благодарный подписчик

$ 11,1 per month
Для всех тех, кому не жалко 1000 рублей в месяц в знак благодарности за мои статьи и ролики. Никаких преференций это пока не даёт, просто поддержка автора.
Go up