Основной, чем основной вопрос о безопасности Spring? - PullRequest
Новая
       12

Основной, чем основной вопрос о безопасности Spring?

3 голосов
/ 29 сентября 2011

У меня очень простой вопрос о безопасности Spring, однако этот вопрос можно обобщить для любой схемы авторизации:

Должна ли группа иметь один орган, а пользователь может быть членом нескольких групп? ИЛИ ЖЕ Группа может иметь несколько прав доступа, а пользователь может быть назначен только одной группе?

Мне нужно, чтобы у пользователя были следующие три полномочия: ROLE_ADMIN, ROLE_MANAGER, ROLE_EMPLOYEE.

Следующие структуры таблицы иллюстрируют вопрос более подробно:

Маршрут 1. 

GROUP TABLE
===========
ID, NAME
1, 'Admins'
2, 'Managers'
3, 'Employees'

GROUP_AUTHORITY TABLE
=====================
GROUP_ID, AUTHORITY
1, 'ROLE_ADMIN'
1, 'ROLE_MANAGER'
1, 'ROLE_EMPLOYEE'
2, 'ROLE_MANAGER'
2, 'ROLE_EMPLOYEE'
3, 'ROLE_EMPLOYEE'

GROUP_MEMBER TABLE
==================
GROUP_ID, USERS_ID
1, 1

USERS TABLE
===========
USERS_ID, NAME
1, 'John Admin'

// -------------------------------------------

Маршрут 2: 

GROUP TABLE
===========
ID, NAME
1, 'Admins'
2, 'Managers'
3, 'Employees'

GROUP_AUTHORITY TABLE
=====================
GROUP_ID, AUTHORITY
1, 'ROLE_ADMIN'
2, 'ROLE_MANAGER'
3, 'ROLE_EMPLOYEE'

GROUP_MEMBER TABLE
==================
GROUP_ID, USERS_ID
1, 1
2, 1
3, 1

USERS TABLE
===========
USERS_ID, NAME
1, 'John Admin'

Буду признателен за ввод.

1 Ответ

2 голосов
/ 29 сентября 2011

Я голосую за: есть Группы с несколькими полномочиями. Но с REAL полномочиями, такими как: ROLE_MANAGE_USER, ROLE_MANAGE_STOCK, ROLE_CREATE_REPORTS, ...

Позвольте мне объяснить, почему полномочия на основе ролей (независимо от того, есть ли у них Маршрут 1 или Маршрут 2) не работают в долгосрочной перспективе.

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

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

Например:

  • Group_Admin: ROLE_MANAGE_USER, ROLE_MANAGE_STOCK, ROLE_CREATE_REPORTS
  • Group_Employee: ROLE_MANAGE_STOCK, ROLE_CREATE_REPORTS
  • Group_Trainee: ROLE_CREATE_REPORTS, MAKE_COFFEE

В вашем коде вы должны использовать только настоящие авторитеты, такие как @Secured("ROLE_MANAGE_USER"), но никогда ничего, что почитает реальным ролям.

Кстати: если ваше приложение становится больше, зачастую недостаточно назначить пользователю только одну роль, тогда вам нужно назначить более одной роли пользователю: user --m:n--> Role --m:n--> Authority.

...