We’re close to start new project using sf2, and, probably, FosUserBundle.
Keeping that in mind – what’s the best strategy to define roles? App will be used by multiple divisions inside our company (every division has it’s manager and regular employees), as well as external users, that can be divided into 3 groups (for now).
I’m comming up with two possible solutions:
-
each role represents specific action in app, i.e.: adding new task action is described as
task_newrole. Selected users get this role to be able to add new task. -
each role represents user ability and every action checks if user has this ability i.e.: when new task is being added, controller checks if current user has role
task_accessrole.
I really somehow like approach to this problem in our current app – there’s one place where only admin has access granted, with list of all registered actions. Users are divided into about 10 groups and all you have to do is to check that this group has access to this action. In this case no code-juggling is required, but I’m afraid it will generate some limitations or roles overgrowing in new app.
What I’m really afraid of is spending too much time changing the security code in specific controller/action, I mean, when new user has to get access to specific place, I will have to go to the code, handle new role, code will grow, and so on. I want to keep this time as low as possible, and as flexible as possible.
I believe there are some great solutions to this problem. Am I right?
To avoid having to touch the code when new roles are thought up, I would use a three-way division in my user/role management:
- Permissions define actions that are possible. For example, you could have separate permissions for read access, write/modify access, create access, modify permissions, etc. You can even let separate modules define separate permission sets.
- Roles represent the set of permissions that groups of similar users will have. For example, Managers, Regular Users, External Users, Administrators
- Users have a role (or possibly more) within the system. This is the level at which authentication takes place.
If a new role is thought up that needs a different set of permissions (for example, a Power User), it is just a matter of adding it to the list of roles and assigning the correct set of permissions.