Давайте рассмотрим довольно простое гипотетическое приложение, в котором пользователи могут читать или писать сообщения.

Некоторые пользователи могут читать и писать статьи, в то время как другие могут только читать их. В Spring Security (3.2.1) я смоделировал это, имея две роли:

ROLE_WRITE: эта роль предоставляет пользователям доступ к написанию сообщений.ROLE_READ: эта роль предоставляет пользователям доступ к чтению сообщений.

Реализация этого с помощью безопасности Spring довольно проста ...

Теперь я хочу также разрешить сторонним приложениям читать и писать сообщения от имени пользователей, внедряя поставщика OAuth2 с помощьюSpring Security OAuth (версия 2.0.0.M3 ATM).

На этапе авторизации приложение спрашивает пользователя, хотят ли они предоставить право читать и / или писать сообщения от своего имени. Пользователь здесь предоставляет области действия (не роли).

Затем, когда потребитель OAuth2 вызывает мой REST API, Spring Sec OAuth авторизует предоставленный токен и создает аутентификацию, содержащую пользователя со всеми его ролями и только предоставленными областями.

Проблема (и вопрос) заключается в том, что теперь мне нужно написать другую логику безопасности в зависимости от того, вызывается ли API пользователем, прошедшим обычную аутентификацию (просто проверьте роли), или он вызывается через OAuth2 (проверьте роли + области).

Можно ли «объединить» понятия ролей и областей в Spring Security OAuth2, чтобы на этапе авторизации пользователь предоставил приложению подмножествороли они есть (и аутентификация OAuth2 только сообщает об этом в предоставленных полномочиях)? Таким образом, когда стороннее приложение выполняет вызов API, роли при аутентификации предоставляются? Таким образом, мне не нужно писать какую-либо логику безопасности для OAuth2.