4

My application has users and administrators. The administrators split into two: super-admin and limited-admin. The super gets all permissions while the limited can be configured to inherit just the admin permissions that are specifically needed.

I am thinking to define my permissions the following way. Any user permission has an administrator permission:
User:
- post_create
- post_update
- post_delete

Administrator:
- administrator_post_create
- administrator_post_update
- administrator_post_delete

Is this a good approach? Should I rather assign to an Admin all the users permissions and then another one like 'administrator_post_manage_all' which bypasses the ownership check and allows an admin to make modification?

Edit
The following rules must be satisfied:

Only some users can create, update, delete posts; however, they must be the owners of the post to update, delete. Every user of the application should be able to read posts. My administrators should be able to update and delete any user's post.

  • If a role is allowed to create a post, is there any difference which role is it? In other words, is creating a post by an admin different from creating a post by a user? If so, maybe it would be better to split the more "powerful" permission into two? Also, have you considered a model without inheritance? From my own experience, role/permission inheritance is a pain. Simpler plain models can often do a trick without making you insane. – scriptin Oct 8 '15 at 18:09
  • I am not using inheritance, used the bad word for describing my issue. – Cristian Oct 8 '15 at 18:28
  • Only specific users can create, update, delete a post that belongs to them. Some users should only be allowed to read a post. An admin should be able to do the same for any user. – Cristian Oct 8 '15 at 18:43
  • So, then it can be modeled with "own_post_???" and "any_post_???" permissions. Also, you can use the concept of context/scope/zone: "own" (for own posts, profile, etc.), "any". So, your roles not just have permissions, but permission within certain context: "admin (role) can read, create, update, and delete (permissions) any (context) post (object)." – scriptin Oct 8 '15 at 19:08
  • @scriptin I edited my post to reflect the rules that must be satisfied. Basically, when I check permissions for a user, I would first check if they have permission to create, update, delete a post and then check if they are the owner. The owner part would not part of the permissions list. On the other hand, an administrator should be able to update, delete any user posts. That means I should have a permission that when encountered would skip the ownership verification. – Cristian Oct 8 '15 at 20:04
4

I've been dealing with these authorization issues in a dozen of softwares ago, and along the way I found this to be the best solution:

  • Permissions shall reflect the events (or requirements) of the system;
  • Users can be assigned to specific permissions;
  • Just use 2 single permissions for CRUD operations by entity - Read and Modify;

CRUD operations: I've never faced a situation that a user can, for example, delete or update an entity but can't create it, so if the user can modify an entity, it is intended that he can create it, update it and delete it.

But according to your requirements, users can read any post and administrators can update/delete posts of other users, so I'd model the permissions this way:

  • post_modify -> Users can create, update and delete posts;
  • post_modify_others -> Users can update and delete posts of other users;

The most important here is that the semantic and meaning of the permissions are totally aligned to your requirements, which makes implementation easier.

So, administrators would be assigned to post_modify and post_modify_others permissions, while users would be assigned to post_modify permission only.

User groups : I usually store users and its permissions in an specific table, but if the number of users and permissions start to grow, it is a good idea to create another table to link users and permissions (for example, user group) in order to make management easier. So you'd have 2 groups - Administrator and Users - and you'd assign users to these groups, according to their roles in the system, and permissions would be assigned per group and not per users.

1

Then I would suggest you think about a general data model for storing the permissions that can handle more complex situations in the future. This answer has a good abstraction https://stackoverflow.com/a/10311479/329496 using a table for permissions, another to link roles to permissions, and another to link users to roles, and another to giving permissions directly to users. You could choose to use that data model and manually insert rows into the tables and work out the queries to load which users have what permissions. Then if your application gets more complex you can add more rows without having to change your queries.

  • I already went through that process. I have exactly the same system of storing roles, permissions. (permissions -> permission_role <- roles -> role_user <- user). I am more interested in how to define the actual permissions. What naming conventions should I use for user's and administrator's assigned permissions. – Cristian Oct 8 '15 at 20:05
  • The action should be "edit_post" and whether the user has that permission should be from a direct join from post->user via the owner column else via the admin role as user->role. The point being that one piece of code should take as input the user and post and output the allowable permissions such as read, edit, delete. – simbo1905 Oct 9 '15 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.