В настоящее время я работаю над бэкэндом spring-boot 2.0REST для веб-приложения. Приложение spring-boot получает токены доступа OAuth2 для аутентификации с ролями, специфичными для приложения, для авторизации. Теперь я хочу защитить различные конечные точки и методы REST на основе ролей OAuth2. Я ищу решение, которое не связывает мой код напрямую с ролями, нет, например @PreAuthorize("hasRole('ADMIN')").
В дополнение к авторизации конечные точки REST должны также возвращать настроенные результаты (например, если запрос содержит действительный токен OAuth2 с ролью «company_A_internal», ответ должен содержать набор результатов, отфильтрованный по «company_A»).
То, что я уже сделал:
OAuth2 с помощью spring-securityOAuth2 с spring-securityGrantedAuthorities, чтобы SecurityContextHolder.getContext().getAuthentication().getAuthorities() возвращал прежние ролиЧто я ищу:
В зависимости от ролей (теперь хранящихся в GrantedAuthorities) конечные точки REST должны быть защищены отдельным механизмом. Я провел небольшое исследование и наткнулся на действительно интересный статья.
Я хотел бы реализовать что-то подобное (например, как отдельный файл role_config.yml):
order_manager:
'/orders':
- 'GET'
- 'POST'
- 'PUT'
- 'DELETE'
order_editor:
'/orders':
- 'GET'
- 'POST'
- 'PUT'
order_inspector:
'/orders':
- 'GET'
Впоследствии мне нужно было реализовать что-то вроде этого в контексте spring-boot:
@Secured
@RequestMapping("/orders")
public void updateOrder (Order order) {
Order updatedOrder = process(order);
return updatedOrder;
}
Как это будет работать в контексте spring-security? Есть ли какой-либо способ реализовать это поверх моей текущей настройки?
Я ценю любые рекомендации и помощь и с радостью отвечу на комментарии и дополнительные вопросы.




Вы можете попробовать https://github.com/vsfexperts/rbac. Вам нужно будет настроить отображение роли в привилегии и аннотировать свои конечные точки с помощью @Secured ("some_privilege"). Просто имейте в виду, что это статично и не позволяет безопасность на основе контента, например. доступ к / orders / 5 не будет ограничен пользователем x, который является владельцем 5. Он будет ограничен только ролью, привилегия которой аннотирована конечной точкой / orders (например, @Secured ("some_privilege")).
Я думаю, что это плохая идея, и блог бесполезен. Во-первых: в файле yaml очень вероятны опечатки для URL. Во-вторых: если вы измените URL-адрес в своем коде (аннотации), вы также должны всегда изменять файл yaml. Кстати: у OAuth2 нет никаких ролей.