роль и разрешение в весенней безопасности 3

Question

Я новичок в ss3, и я прочитал его ссылку, а также я прочитал книгу безопасности Spring.

Однако я не нахожу ничего о роли-разрешении.

Например,, вот конфигурация для аутентификации на основе форм.

  <http auto-config='true'>
    <intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
    <intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>
    <intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
    <intercept-url pattern="/**" access="ROLE_USER" />
    <form-login login-page='/login.jsp'/>
  </http>

Я хочу управлять пользовательской операцией (добавить / удалить):

<intercept-url pattern="/user/add/**" access="hasRole('USER_ADMIN')"/>
<intercept-url pattern="/user/delete/**" access="hasRole('USER_ADMIN')"/>

Я определяю роль 'USER_ADMIN', но этого недостаточно, поскольку я хочу отличить пользователя, у которого есть разрешение «добавить», от пользователя, у которого есть разрешение «удалить».

Может быть, я могу добавить больше ролей, таких как «user_admin_add» и «user_admin_delete».

Но я не думаю, что это хорошая идея, поскольку «добавить» или «удалить» - это разрешения, а не роли.

Как это сделать?

Кроме того,кажется, что все роли должны быть настроены в XML-файле, интересно, могу ли я динамически добавлять новые роли и разрешения (на странице администратора)?

Answer 1

Возможно, я смогу добавить больше ролей, таких как 'user_admin_add' и 'user_admin_delete'.

Это путь. Разрешения - это роли, и обычно есть люди, которые считают различие между ними ненужным.

Не думаю, что есть большая разница в роли ROLE_USER_ADDER или разрешении PERMISSION_ADD_USERS .

Однако вы можете использовать роли в качестве концепции для группирования разрешений, если вам это необходимо. Например, у вас может быть роль администратора, которая может добавлять и удалять пользователей. Таким образом, роль ROLE_ADMIN будет иметь PERMISSION_ADD_USER и PERMISSION_REMOVE_USER . Тем не менее, весна будет рассматривать и роли, и разрешения просто как авторитет.

Что касается добавления динамических ролей, вы можете сделать это, загрузив, например, разрешение текущего пользователя из вашей БД. Взгляните на UserDetailsService пружинной безопасности. Возвращаемый им объект UserDetails имеет метод getAuthorities(), который вы можете заполнить из своей БД.

/**
 * Returns the authorities granted to the user. Cannot return <code>null</code>.
 *
 * @return the authorities, sorted by natural key (never <code>null</code>)
 */
Collection<GrantedAuthority> getAuthorities();

Здесь - очень хороший пример реализации вашего собственного UserDetailsService.

Answer 2

Думайте о ролях как о привилегиях.И гранулируйте их столько, сколько вам нужно.Другое дело, что, возможно, вам следует сделать более RESTFul реализацию.Но это другой поток.

Например, ваш "delete" может быть методом "DELETE" HTTP.Тогда вы можете быть:

<security:intercept-url pattern="/users/*" method="DELETE" access="ROLE_DELETE_USER" />

и curl -X DELETE -u login:password 'http://example.com/users/1'

удалит user с идентификатором 1.

с помощью RESTFul, поскольку Urisлибо идентификаторы, либо действия, бесполезно динамически добавлять роли (привилегии).Поскольку эти роли предназначены для использования с новым ресурсом, который должен содержать файл xml.

Боюсь, вы не сможете сделать это, если не используете ** подстановочные знаки.Что, по моему мнению, при неосторожном использовании может привести к неприятностям.

Answer 3

По моему личному мнению, у весенней безопасности есть несколько (скажем так) неудачно выбранных имен. Поэтому не обращайте так много внимания на термин «роль», он отлично работает, если вы используете его для привилегий.

В моих приложениях используется соглашение об именах для выбора ролей и привилегий. (роли пишутся в верхнем регистре, привилегии в нижнем регистре). Но обратите внимание, что Role Voter будет обращать внимание только на те строки, которые начинаются с «ROLE» (конфигурация по умолчанию может быть изменена).

См. Также Авторизация на основе группы безопасности Spring

Answer 4

Вы должны думать о ролях больше по типу ролей, а не по разрешениям.Если вы хотите различать добавление и удаление пользователей, вы можете определить роли, описанные как ROLE_SALES и ROLE_USER_ADMIN.Торговому персоналу вполне может понадобиться добавить новых пользователей в систему.

Что касается динамического применения ролей, вам следует взглянуть на архитектуру Spring Security.Скорее всего, вы захотите использовать или реализовать подходящий UserDetailsService.См. Справочную документацию UserDetailsService .

. Например, если вы храните информацию об авторизации пользователя в базе данных JDBC, вы можете использовать JdbcDaoImpl .

Есть несколько примеров использования разных поставщиков аутентификации во введении пространства имен .