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

Донаты в Boosty: https://boosty.to/akosarev/purchase/1451735

Донаты в Tinkoff: https://www.tinkoff.ru/cf/4PEOiVCZQuS

Вячеслав Лапин

Интересно, почему же их решили удалять?.. Из критики, нашёл лишь статью 12-го года - https://agoodcoder.blogspot.com/2012/04/alternative-to-spring-security-acl.html . Там следующие 4 пункта:
"Spring Security ACL может быть хорош, но его недостатки также очевидны:
1. Необходимо сохранять разрешения вместе с сохранением каждого бизнес-объекта
2. Необходима аннотация для каждого метода
3. Если вы решите изменить настройку прав доступа, вам придется проделать огромную работу по изменению производственных данных, а это проблематично и опасно.
4. Вероятно, у вас уже есть структура разрешений. Например, контракт создан пользователем UserA, поэтому только UserA может его изменить. Вы сохраните дублирующуюся информацию в ACL. Почему бы просто не использовать существующую структуру, которая у вас уже есть?"

Dec 22 2023 14:30

Уголок сельского джависта

Вячеслав Лапин, я лично вижу три причины:
1. Решение хоть и рабочее, но недостаточно гибкое, единственная реализация подразумевает использование реляционных СУБД в качестве источника данных.
2. Откровенно слабая документация - если попытаться всё сделать, как описано в ней, то не взлетит. Надо рыться в исходных кодах. Это сильно повышает порог вхождения, который и так достаточно высокий для ACL в целом.
3. Непопулярность. Обычно такие решения пилятся самостоятельно с интеграцией в существующую систему прав..
Критика меня порадовала)
1. Очень странная проблема) Нужно понимать, что ACL как правило реализуется в виде технической предметной области и существует самостоятельно, без реальной привязки к объектам предметной области. Можно при помощи АОП это всё автоматизировать.
2. Тоже странная проблема, аннотации, что с ACL, что без нужны.
3. Рабочий процесс, причём очевидный
4. А это демонстрирует отсутствие понимания автором ACL)

Dec 22 2023 15:05

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

Subscription levels