7 июля 2022
Блог
Настройка гибкого доступа к окружениям с помощью Spring Security ACL
Нередко случается, что ресурсы могут быть зависимы друг от друга, и это делает настройки правильного доступа непростой задачей. В одном из наших проектов мы создали гибкую механику разделения прав, используя ACL (Access Control List) с его реализацией для Java в виде библиотеки Spring Security ACL. На примере этого проекта расскажем, как мы подружились с библиотекой, чтобы все заработало.
В нашем продукте есть три иерархичных уровня ресурсов:
- организация;
- проекты организации;
- окружения проекта.
На каждом уровне мы описали набор операций, которые могут быть выполнены с сущностью. Например, для организаций доступен следующий список операций:
- просмотр организации;
- редактирование информации об организации;
- просмотр списка участников в организации;
- добавление в организацию;
- удаление участника из организации;
- редактирование прав участников;
- добавление нового проекта в организацию;
- удаление проекта.
Теперь нужно определиться с набором прав, который будет покрывать список этих действий. Если бы мы хотели регулировать права на каждую операцию в отдельности, то набор прав в точности повторял бы набор операций. Но в данном проекте мы могли себе позволить сгруппировать некоторые операции под одним правом:
- READ_ORGANIZATION – просмотр организации;
- EDIT – редактирование информации об организации;
- READ_MEMBERS – просмотр списка участников в организации;
- EDIT_MEMBERS – добавление и удаление участника в организацию, редактирование прав участников;
- CREATE_PROJECT – добавление нового проекта в организацию;
- DELETE_PROJECT – удаление проекта.
Такое же упражнение выполнили для проектов и окружений. Для проектов получился следующий набор прав и соответствующих операций:
- READ_PROJECT – просмотр проекта;
- EDIT – редактирование информации об организации;
- CREATE_ENV – добавление нового окружения в проект;
- DELETE_ENV – удаление окружения;
- READ_MEMBERS – просмотр списка участников в проекте;
- EDIT_MEMBERS – добавление и удаление участника в проект, редактирование прав участников.
Используя описанные для сущностей права, можно создать любые необходимые в системе роли. Например, в нашем случае у тимлида есть все права на уровне своего проекта и только чтение – для организации. А разработчик может только читать данные внутри проекта и организации.
Экран пользователей внутри проекта. Здесь видно, что у юзеров есть разные разрешения для работы на окружениях:
Spring Security ACL поддерживает наследование прав – при необходимости можно сделать так, чтобы права на родительскую сущность означали наличие прав и на дочерние. В нашем случае это было важным требованием, так как в проекте подразумевается четкое разделение ресурсов (организация – проект – окружения) и ролей.
Еще одно преимущество в том, что Spring Security ACL – это библиотека экосистемы Spring`а. Это значит, что ее интегрирование в любой проект на платформе Spring Boot будет очень простым. И бизнес-процесс на самом деле практически не поменяется.
Например, в нашем проекте изначально были детально проработаны бизнес-требования, а затем отдельной итерацией мы работали над правами и доступами. Как раз благодаря тому, что можно просто добавить в зависимость эту библиотеку, при добавлении работы с правами не пришлось сильно менять логику работы в коде. В большинстве случаев было достаточно использовать аннотации Spring`а, которые добавляются над методами. А это автоматически включает в себя работу с правами, но не меняет логику.
Преимущества Spring Security ACL
- Реализация гибкой модели назначения прав, с атомизацией разных доступов и возможностью выдавать их по отдельности для каждого ресурса;
- Простая настройка библиотеки ACL с минимальными изменениями бизнес-логики;
- Работа с правами не затрагивает сценарий существующего кода;
- Возможность поддерживать иерархию наследования прав;
- В архитектуре библиотеки заложена возможность кастомизации настроек под нужды конкретного проекта;
Решение можно легко масштабировать на любой другой проект.