Угу. Просто хотелось выяснить, возможно ли это сделать средствами Spring Security, если нельзя, то не тратить время на изучение, и реализовать функционал самому.
По поводу AuthenticationProvider не совсем понял, как он мне поможет при авторизации (не аутентификации). Буду изучать архитектуру, угу.
1. Приложение сдаётся заказчику, и он должен иметь возможность сам создавать роли и назначать им соответствующие права. Пересобирать приложение и перезагружать его он не будет.
2. Будет админская (единственная известная заранее) роль. Первоначально базу можно заполнить и при помощи sql запросов.
вы путаете role specification, role mapping и role assignment. role specification - т.е. указание, какие роли какие методы могут вызывать - вещь довольно статическая и задается на уровне дизайна. я не видел, чтобы кто-то парился от перезагрузки-передеплоя, который при этом необходим.
role mapping - какие роли каким эквивалентны, какие роли у каких наследуют. сие можно реализовать динамически, но не имеет отношения к "какие методы вызывать". это задается на уровне бизнес логики.
role assignment - какие юзера в какие роли мапятся. сие тоже динамическое и driven by бизнес логика.
хм, возможно, задавать эквивалентность ролей, это выход.
Я правильно понимаю, что, если я хочу достигнуть поставленной задачи, мне придётся завести большую кучу ролей для role specification? То есть, к примеру, для справочников книг, пользователей завести роли: ROLE_BOOKS_EDIT, ROLE_BOOKS_READ, ROLE_BOOKS_REPORT, ROLE_USERS_EDIT, ROLE_USERS_READ,.. и т.д. для каждого справочника по несколько своих ролей. И для них уже указывать, какие методы каких классов они могут вызывать.
А потом уже маппить роли как захочу: "зав. склада" -> "ROLE_BOOKS_EDIT, ROLE_BOOKS_READ, ROLE_USERS_READ" и т.д.? (пример вымышленный)
В двух словах, всё делается, но чем проще задача поставлена, там проще она реализуется.
Для начала смотреть DaoAuthenticationProvider и UserDetailsService. Там в два счета реализуется чтение ролей из БД. Вот простейшая конфигурация в тройке:
Проще всего сделать много ролей (на каждый чих), и объединять их в группы. Пользователи, группы и роли моделируются в БД и в два счёта конфигурируются через JdbcDaoImpl. Соответственно то, что Вы обозначили в виде "редактирования ролей" это, на самом деле, редактирование групп. И всё будет работать чуть-ли не из коробки.
Если же всё же хочется пожрать кактусов, то ключевое слово AccessDecisionVoter. См., например, как security:global-method-security работает. В частности см. PreInvocationAuthorizationAdviceVoter, ExpressionBasedPreInvocationAdvice. В принципе, реально сделать редактирование доступа на уровне чуть ли не метода, но путь этот изрядно тернист и крив.
Comments 9
(The comment has been removed)
По поводу AuthenticationProvider не совсем понял, как он мне поможет при авторизации (не аутентификации).
Буду изучать архитектуру, угу.
Reply
2. если все настолько динамично, как вы собираетесь обслуживать запросы, которые начались ДО изменения ролей?
Reply
2. Будет админская (единственная известная заранее) роль. Первоначально базу можно заполнить и при помощи sql запросов.
Reply
role mapping - какие роли каким эквивалентны, какие роли у каких наследуют. сие можно реализовать динамически, но не имеет отношения к "какие методы вызывать". это задается на уровне бизнес логики.
role assignment - какие юзера в какие роли мапятся. сие тоже динамическое и driven by бизнес логика.
Reply
Я правильно понимаю, что, если я хочу достигнуть поставленной задачи, мне придётся завести большую кучу ролей для role specification?
То есть, к примеру, для справочников книг, пользователей завести роли: ROLE_BOOKS_EDIT, ROLE_BOOKS_READ, ROLE_BOOKS_REPORT, ROLE_USERS_EDIT, ROLE_USERS_READ,.. и т.д. для каждого справочника по несколько своих ролей.
И для них уже указывать, какие методы каких классов они могут вызывать.
А потом уже маппить роли как захочу: "зав. склада" -> "ROLE_BOOKS_EDIT, ROLE_BOOKS_READ, ROLE_USERS_READ" и т.д.?
(пример вымышленный)
Reply
(The comment has been removed)
Reply
Для начала смотреть DaoAuthenticationProvider и UserDetailsService. Там в два счета реализуется чтение ролей из БД. Вот простейшая конфигурация в тройке:
Проще всего сделать много ролей (на каждый чих), и объединять их в группы. Пользователи, группы и роли моделируются в БД и в два счёта конфигурируются через JdbcDaoImpl. Соответственно то, что Вы обозначили в виде "редактирования ролей" это, на самом деле, редактирование групп. И всё будет работать чуть-ли не из коробки.
Если же всё же хочется пожрать кактусов, то ключевое слово AccessDecisionVoter. См., например, как security:global-method-security работает. В частности см. PreInvocationAuthorizationAdviceVoter, ExpressionBasedPreInvocationAdvice. В принципе, реально сделать редактирование доступа на уровне чуть ли не метода, но путь этот изрядно тернист и крив.
Reply
Reply
Leave a comment