Использование областей в роли Spring Безопасность OAuth2 (поставщик)
Рассмотрим довольно простое гипотетическое приложение, в котором пользователи могут читать или писать сообщения.
Некоторые пользователи могут читать и писать статьи, а некоторые другие могут читать их только. С помощью 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.
Ответы
Ответ 1
Области (и роли) - это произвольные строки, поэтому нет проблем, если вы хотите сделать то же самое. Чтобы сделать объявления с правилами доступа одинаковыми, вы можете написать ExpressionHandler, которые проверяли полномочия или области с теми же значениями в зависимости от типа найденного Authentication.
При чтении комментариев появляется другой подход: добавьте пользовательские TokenStore или ResourceServerTokenServices. Это легкодоступные точки расширения и позволяют изменять OAuth2Authentication так, чтобы его предоставленные полномочия были такими же, как области.
Мое предпочтение, однако, состоит в том, чтобы управлять разрешенными областями с помощью OAuth2RequestFactory, ограничивая их в точке предоставления маркера равными значениям, которые согласуются с полномочиями пользователя.
