I am trying to come up with the best practice on how to set up roles for my controllers and actions.
We have a debate in our office. Should we give one role to the user and decorate our controllers and actions with a list or roles, or viceversa, multiples roles to an user and have controllers/actions decorated with the minumum access role required?
In my experience, it has been better to allow a user to assume multiple roles. This is the most flexible approach, and it will avoid an explosion in the number of roles in the system, because different people often wear different hats within an organization. This also simplifies your controllers/actions because you only need at most one role per.
I think this depends entirely on what you want your users to be doing. Is a person in an admin role only going to be able to do admin type things or everything?
We had a similar issue come up and we decided to go with 4 different roles and assigned multiple roles to users based on what they needed access to.
Related
Since I had problem with Passport multi auth, I wonder is it necessary to have an admin guard (and an admins table) or it's better to use the default guard (and users table) for both admins and users with the help of role and permissions? Which is better?
That's a really hard question to answer without more information, but I'll try looking at it from a few perspectives:
You have an application that has users that can turn into admins (and vice-versa)
In this situation, I would probably have a single table that contains an is_admin column and use the column to validate whether the user can perform administration tasks (e.g. by using Laravel's gates). The downside to this is that if you wanted to create a third type of user (e.g. supervisor), you would need to change the model used.
You have an application where users are completely separate from administrators
If you control the administrators and everyone else is just a user, creating separate guards could be used, this does allow for a lot of flexibility in the future if you wanted to implement different authentication flows for both administrators and users (for example, using SAML). If you were to add a third type of user (e.g. supervisor), you could then just create another guard.
You have an application that can have different (customisable) permissions for each user
In this case I would recommend implementing a roles table, a permissions table, a role_permissions table and adding a column called role_id to the user table. This provides the most flexibility and is also usable with the Laravel's gate system, but is probably the most difficult to setup and hardest to maintain.
For the application I develop, we use a mixture of roles and guards. We use roles for users as each user gets a customisable set of permissions. We then use a separate guard for API users which inherit the permissions of the user they were authenticated with.
I want to create a RBAC system in laravel where a user can belong to several roles, and each role can have several permissions. The middleware should check if the user has a certain permission (within any of their roles) before it continues with the request.
I am able to implement a case where
A user belongs to one role which has many permissions
A user belongs to several roles which are used to determine access control (without the permissions bit)
I need to implement a user with multiple roles having multiple permissions. Any pointers?
If you are not interested in coding this yourself the a package like Laravel permissions would do exactly what you want.
https://github.com/spatie/laravel-permission
Otherwise you need to create pivot tables between the users ans their roles and the roles and their permissions
So you would have a user_roles table that would consist of user_id and role_I'd.
You would also have a role_permissions table which would have role_id and permission_id.
This would allow you to have many to many relationship and have many through relationship to get straight from user to role and role to user.
Hope that helps
As an overview. You need to have a roles table in your database which defines different types of user's your application can have , Like (Admin, Author, Editor, Moderator etc)
You also need to define a table role_user which contains data on which user has which role. This will be a Many to Many relationship since a user can have multiple roles.
Next you need to define a Middleware CheckRole which basically checks if user has a particular role. You can use this Middleware on different parts of your application to restrict authentication.
You might find this tutorial useful :
https://www.5balloons.info/user-role-based-authentication-and-access-control-in-laravel/
I am about to define permissions for users in my project. I checked the laracasts videos regarding ACL, Roles and Permissions.
I have a doubt. Do I need Roles for normal users?
I mean, in my project a user should be able to create / update / delete his own posts, he should be able to comment on his own posts and posts by other users and delete his posts and posts left by others on his own posts.
The point is: do I really need to define Roles for this kind of permissions? Shouldn't I just define some policies like can / can't post / update / delete etc. and only define roles for admins?
You don't necessarily need a full featured, powerful Roles/ACL system but if you are storing both admin and basic users in the same table then you do need something to distinguish between them. This could be something as simple as a Role field as a string on your users table e.g. Admin or Basic, or even a boolean is_admin field.
This would give you the ability to implement a Policy or Middleware to prevent basic users accessing the admin panel, and you can have permission checks to ensure a user can't update other users posts etc.
If you don't foresee needing anything more complex in future then this would suffice. However, as your app becomes more mature, you might wish to have a more advanced roles system, for example where a user needs to have multiple roles.
You don't necessarily need to define a role for every user...
It's probably a good idea to, however, you can 'hardcode' and make some assumptions about some of the access...
For example:
If you assume that anyone who is logged in can make a post and can edit their own post, you don't need to make a role for users to say "can_make_post", just have a check saying "if user is logged in, then let them make a post"
then if you say, have an admin area, then you can go "if user a has role
with the 'admin_access' permission, then allow access"
It would be a good idea to have roles for everything, as it allows more customisation, however, your the one designing it, if you don't need the customisation, you can probably just make some assumptions like above.
since laravel's built in authentication uses user model? For example I want to separate the admin from the user so I will build two different layers in my application, the admin and the user. How can I achieve this to laravel since it's default auth uses users table and user model?
In my opinion, there's no real need to separate the two. Administrators and typical users can exist on the same database table, because they are both users but can have different permissions.
It seems like you're just looking for a typical permissions system (ACL). There's multiple packages available that can help you handle this.
Orchestra Auth
Sentinel
Entrust
Normally as an admin is still an user you give them a role column and let say you have : users, moderators and admins. Then you got role 0,1,2 for them. Just make it an enum and if you need to check in Laravel use : Auth::user()->role == 2 for example of admin rights :)
We are trying to implement Custom Role membership provider for our web app. For authorization we want to check for one more field like Facilityid for the logged on user along with role he has. eg. my User1 having Role1 with Facility1 can access some option and same user role for Facility2 have different option. So is there a way we can extend the existing role/profile provider to authorize user with this additional field along with role assigned.
Depending on how complicated you expect this to be you might want to just have Facility1 and Facility2 be roles, even though they may share a lot of the same aspects. In this manner, you should not need to extend the membership provider.
There can be n facilities so having those many roles does not look fesiable. If we can find a way by which we can pass the Facilityid from the application to this security module roleprovider and fetch appropriate role for user only for that facility.