Basic than the Basic-est question on Spring Security?

I have an extremely basic question about Spring security, however this question may be generalized to any Authorization scheme:

Should a Group have a single authority and a user may be a member of multiple groups? OR A group may have multiple authorities and a user may be assigned to just one group?

I need a user to have the following three authorities: ROLE_ADMIN, ROLE_MANAGER, ROLE_EMPLOYEE.

Following Table st开发者_如何转开发ructures illustrate the question in a bit more detail:

Route 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'

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

Route 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'

I'll appreciate an input.

I vote for: have Groups with several autorities. But with REAL Authorities like: ROLE_MANAGE_USER, ROLE_MANAGE_STOCK, ROLE_CREATE_REPORTS,...

Let my explain why the Role based authority (no matter if Route1 or Route2) does not work in the long term.

If the real user groups are not fixed for ever (and that is it for every real application) then you will have the problem, that in some point in time you will need to support a new group, for example trainee. If you now have used real role names for your authorities like "ROLE_EMPLOYEE"... then you need to go through the code and modify every security statement that guard a function that should be available for trainees too.

But if you use real authorities for the authorises, and build an assignment between real groups and authorities then you will only need to define the new group and the assignment to the authories.

For example:

• 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

In your code you should have than only use real authorities like @Secured("ROLE_MANAGE_USER") but never anything that reveres to real roles.

BTW: If your application becomes bigger it is often not enough to assign only a single role to an User, then you need to assign more then one role to an user: user --m:n--> Role --m:n--> Authority.