The current ACL of phalcon is managing access between roles, resources and its actions. For example, if we want to allow specific role into specific resource :
$acl->isAllowed("Guests", "Customers", "search");
This check if role called "Guest" can access "Customers" controller for action "search".
In my scenario, we also have "Role Level", for example, Admin can access all modules and controllers, but, to modify the contents, an Admin should have minimum Role Level 2. To gain access to modifying website configuration, an Admin should have Role Level 3.
In addition to role level, we also want to assign which models a role can have access to. For example, Mr. A and Mr. B both are Admins and have same levels. But, we decided only to allow Mr. A to access "Accounts" models while Mr. B can have access to "Accounts", "Personnel", etc.
Here are my questions :
Does phalcon ACL support roles and levels ? Or, should I just create the custom validation?
What is the benefit of using ACL compared to creating similar validation functions?
If I have to create custom validation, where should I put it ? In the controller, or in the dispatcher ?
Thx
At the moment Phalcon does not support Role based ACLs. You will have to do something yourself to cover this. The feature has however been asked for and it is in the long list of NFRs for the project :)
The way I would go about it is use a combination of Phalcon functionality and custom programming. I would add everything to a base controller in the beforeExecuteRoute function so that whenever something is to be dispatched ACL is checked.
In a similar project to yours, I created two tables in my database:
Groups
------
group_id <- 2
group_name <- Admins
and have an ACL table that maps all actions to a group like so
ACL
---
group_id <- 2
acl_controller <- Customers
acl_action <- Search
You can easily extend this to have a collection of controller/action pairs to map to a Role. From there you can just create a simple function that would load the role based resources.
It is a bit of a workaround but it works.
Related
I'm new to laravel and don't have much experience in it.
There is a scenario of defining access levels in a laravel project. Our team has decided to use spatie package for implementing different access levels.
I know, how to implement basic roles and permissions but in our case, we're following an application where we have 3 basic roles:
1. Full Admin
2. Employees
3. Managers
In Employee role we further have sub-roles, like UK-Employees, US-Employees, FullTime-Employees, etc.
These different groups/roles have different permissions, which we can change according to our needs.
On the index page of Access Levels, we can create a new role by deciding which type of role we want to create? Employee/Manager/Custom. On selecting one role, we go to another page and on that page, we get some predefined permissions according to the role type (Employee, Manager or Custom). Further, we can change those permissions to define new roles.
Can anyone suggest to me how can I implement this scenario using spatie?
Moreover, if the question is not understandable please suggest edits.
I try to find a way that allows me to recover the strongest role from the list I defined in the security file Symfony security.yml
Suppose I have the following hierarchy :
ROLE_A: [ROLE_B,ROLE_C]
ROLE_B: [ROLE_D]
In a method that I have to develop, I am supposed to pass a role list (A, B and C) in this case and recover the strongest role (A).
Can you come up with ideas?
I had the same issue. Out of luck, I had to have the role hierarchical logic in User Entity like in an associative array.
Then create a method as getParentRole() to return desired parent ROLE.
OR
If you are using FOSUserBundle and your Application needs a group level classification of User entity, Consider using Group feature available in FOSUserBundle
Hope this helps!
I'm looking for a solutions where I can do the following in my Sonata backend:
In my database I have the following tables:
roles
id
name
role
is_super_admin
weight
permissions
name
permissions
description
role_permission (many to many)
role_id
permission_id
So I would like to save relations in my table role_permission. But I'm a bit stuck on how to do this in Sonata admin. Can I do this in the list view? And if yes, can you help me on my way?
Not sure if OP wants to implement custom roles or use existing features. However I would recommend using a single role system. Sonata already has handlers for security so in my opinion it would be best to use those instead of creating your own.
On the sonata site, there is a section in the admin bundle about security. Which explains how to setup certain types of role management. I would either go for the Role or ACL handler depending on what you need.
When enabling the role handler you can create groups of roles. These groups would serve as your "Role 1". For example I could create a group called "Beta Testers" and give them the ROLES (permissions) ROLE_CHECK_BETA_CONTENT and ROLE_BETA_FEEDBACK_FORM. Now if you want normal users to not have these rights you could create a normal user group and assign every other role (permission).
Let's begin by saying that my model classes are User and Entries.
I've read the following tutorial: http://book.cakephp.org/2.0/en/tutorials-and-examples/simple-acl-controlled-application/simple-acl-controlled-application.html and I see they use an extra model called Group in order assign a role to users.
What is different in using a Group model, instead of a role attribute in User (User.role = 'admin')
What is the difference in adding Group to the ARO instead of adding User to the ARO, and then using an alias.
If I implement ACL, does that means I no longer need admin routing?
PD: I am new to ACL list, I have always authorized actions using a something like if($user['role'] == 'admin').
These are two different ways of handling authentication. If you only have a few controllers and one or two admins, you'll probably be fine with using the User.role method you have now. If you have multiple controllers and various users who should have access to different sections of your site, you should use ACL.
You don't need to create Groups to use ACL, but it makes life a lot easier. Instead of assigning permissions for dozens of different users, you can create two or three groups, set the permissions for those groups, and then assign each user to one of the groups. Then, if you ever need to add a new controller -- or even a new view -- you only have to do that at the group level, instead of for each user. (Take a look at this demo. Now imagine that you have another 10 controllers/50 actions and you have to set those permissions for 20 or 30 users instead of for 4 groups.) Of course, even if you are setting permissions at the Group level, you could always override them at the User level if you need to.
Admin routing is separate from ACL. Routing just controls the URLs you can use to get to pages. (See Cake PHP - Prefix Routing. You can use ACL control without admin routing, and you can use admin routing without ACL control.
I have been reading about ACL and it is quite interesting but I am not sure if ACL is a right tool for my new backend system.
I want to restrict certain features from User Groups and Roles, for example:
"Processing" group can see a category dropdown but it will be hidden from a "Sale" team.
"Processing" group a see a few options in a category dropdown. Admin group can see everything.
If I add a new group called "Training" - I would like a "Training" team to have access to
a category dropdown.
Is ACL right tool for this? If so - how can it be done.
Access control list - list of permissions attached to an object. It specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. - wiki
So it fits exactly to your problem.
Create actions, users and then just set actions for the users. Or create groups and set the actions for the group and then put the users to specific group.
ACL - access control lists - is a good starting point but you probably want to look at more advanced authorization models for instance role-based access control and later attribute-based acccess control. NIST has defined these two models extremely well:
NIST RBAC: http://csrc.nist.gov/groups/SNS/rbac/
NIST ABAC: http://csrc.nist.gov/projects/abac/
RBAC and ABAC will scale better than just ACLs.