I am using Acl in new web app.
in my app there are four groups of users.
I have given $this->Auth->authorize = 'actions' so that it will check the permission for actions automatically.
my problem is some of the actions such as change Password,edit profile,etc...
are common to all users.
But now i need to create each record for the permission of each users in acos_aros table.
this is too annoying
1) Is there any way to give permission to all types of users with a single allow statement?
2) Is there any way to allow and deny user by checking whether parameter is passed or not?
that means i need to give permission to pass parameter to an action for a specific user. If any other user pass the parameter and try to access the data i need to deny them.
whether row level access control can be done with ACL?
Any help will be appreciated.
Thankz in advance :)
If you put a $this->Auth->allow('action1','action2'...) into your beforeFilter() of the controller, access is granted to all users. If you need an ACL-only solution, you have to create a parent aco to which all other acos you want to allow are children. Then grant your users the rights on the parent.
The ACL plugin from the bakery could come in handy, if you already have your ACL tree structure.
For building the ACL tree structure the build_acl() script in the tutorial at the end of the cake-manual is useful.
Allowing to pass the parameter for all users and checking their role in the action is not an option?
the solution for the 2nd problem is here
but this is not implemented using ACL :(
Related
I'm currently working on a project where a user can have many roles, and each role has assigned one or many permissions. Permissions describe the actions that a user can apply to ressources. For example let's consider that I have three ressources that I can interact with using my API : users, books, payments.
I'd like to have all users able to update their personal informations like phone number... etc. This led me to give update permission on user's ressource for all users. But the problem is that I want them to be able to updates their own profiles only. Furthermore, some users have admin permissions and can change other users permissions, therefor they have another kind of update permission on user's resource.
So my question is : what's the best way to design the permission table. Below you can find my schema design. Thank you for your answers in advance.
User(firstName string, lastName string, roles Role[])
Role(name string, description string, permissions Permission[])
Permission(name string, effect 'Allow' | 'Deny', resource string, action string)
Well I am not entirely sure what you meant by resource and action. If you meant URI template and HTTP method, then ok. Otherwise you might need a different solution or somehow add parameters to your design if you want to allow or deny individual resources per id.
If we are talking about a REST API, which I assume, then you can do something like PATCH /api/v1/current-user/profile {...} for updating your profile and PATCH /api/v1/users/{user-id}/profile {...} to update somebody else's profile. If you meant controller classes and their methods, then you can do the same with two different controllers, something like CurrentUser.partialUpdate(params) and User.partialUpdate(params).
As of updating user permissions, I wonder how to do it, because you can update only role permissions and give or take away roles for the users in your model.
Another thing I don't understand that why do you need the allow|deny flags. If roles collide because users can have multiple roles or permissions collide, because you can both allow and deny the same thing, then how do you resolve it without a hierarchy? And if you don't have a hierarchy, then this flag is completely useless and just deny all and allow what is added to the role.
As of the one user multiple roles approach it is not a great idea, at least in places where people take security seriously a single account or at least a single session can have only a single role. Since this would make a lot of repetition I would solve this on a role level and make composite roles or support role inheritance. So for example the Administrator role would be the composite of the OwnProfileEditor and ProfileEditor sub-roles, which I would rather call Features or Capabilities or PermissionGroups rather than Roles.
Usually RBAC is not that flexible, so people tend to add per User Permissions to override Role Permissions. I would not do it, because you will end up with a mess if you follow that approach.
I hope you're fine, this is my first question and I really don't know where to start from, so here it is,
I've been trying to build a sample with Microsoft Web api Template where I have to authorize users based on roles for example "Admin, Moderators, etc..." so, the thing is the I don't want to put all those roles on the top of the controller like
[Authorize ( Roles ="Admin, Moderators, etc...")]
I see this as not a good practice because What happens if I create another role in my db? I will have to modify the controller to add the new Role xD, really bad, isn't it? so the question is. How to extend some class like AuthorizeFilter to get the roles from database and validate with the controller? I mean if there is a user who is in the role admin authorize it and viceversa?
the other question is How to build a great authorzationfilter which can manage something like if a user if in Moderator Role but the only right he has is to user the Create action in the controller?
I hope you can help me with an example...
Thanks in advance
Ps. Sorry for my english
I agree role based authorization is somehow limited and authorize attribute is a bit rigid.
In some scenarios role based authorization is not enough, you need to extend it. You can introduce the permission concept. Instead of be a requirement that you have to be a member of a specific role to execute an action, you could state that to be authorized to execute an action you need a specific permission. So instead of authorize attribute you use RequiredPermisionAttribute. Of course you need to write RequiredPermissionAttribute as an authorization filter.
In the database you have the Permissions Table, the RolesTable, the RolePermissions table and UsersInRole table.
So a user can be a member of one or more roles. A role can have one or more permissions. A user has a specific permission if he/she is a memeber of a role that has that permission.
The required permission filter checks if the logged in user is a member of a role that has the permission, if not, then returns 401 not authorized.
This is a more flexible approach, actions are not tied to roles and roles don't have a fixed number of permissions.
I want to do a role based access for the pages in AngularJS.
Based on the role pages should be shown to the user.
Can any give me an example? Which should be a best solution.
To access the page based on the role is very easy.
Suppose if the web/dashboard have three roles like admin, support, employee.
assign the field as userrole to the users.
Now assign the roles for those pages as ng-if="userrole=='admin'" or vice versa
now based on the roles the pages are accessible
I'd suggest you take a look at (in the following steps):
Decide on an approach for accessing the current users role.
Look into ui-router, specifically it's Resolve method.
Run some third function inside the Resolve method to see if the user is of the correct role, and handle your cases in what way you will.
Something I worked on a while back had an Authenticate method running in the Resolve method, you may want to have a look at that for reference. This was not role based however, but it may give you a nudge in the right direction.
Routes:
https://github.com/kasperlewau/metalmarket/blob/master/app/assets/javascripts/config/routes.js
Auth Service: https://github.com/kasperlewau/metalmarket/blob/master/app/assets/javascripts/app/services/auth.js
If anyone has a better idea for role based / logged-in based authentication, I'm all ears.
I'm implementing the ACL component for my CakePHP app (1.3.14). I have everything setup correctly, but there are a few areas where I'm still fuzzy.
Mainly, do I need to explicitly set rights (ACOs) for a special base user group (AROs)?
For simplicity, let's say I have Administrators and then everyone else (general users). So do I need to create a group for these general users and map all their allow rights? Seems like management of these rights would be never ending as the app grew.
Also, what about assigning users to multiple groups?
Ideally if a person had a user account the Auth component would grant access to the system as a whole. Then ACL would simply deny them from the sections that were protected by an existing group.
It seems like the coupling of ACL and Auth is too high. But it may be my new (limited) understanding. Any clarification would be greatly appreciated.
UPDATE
I've started a bounty. In summary, I want to implement CakePHP ACL (preferably, but a matching third-party component is acceptable) that meets/addresses the following:
Assign users to multiple groups
Easily maintain a "public" user group - don't have to constantly add the controllers/actions a general user can access
Code example of managing access to a controller/access
Code example of properly testing a user belongs to a group.
I think the best you can hope for using Cake's native ACL implementation is something like the following:
cake acl create aro root public
cake acl create aro root registered
cake acl create aro registered administrators
(create acos using AclExtras)
cake acl grant registered controllers
cake acl grant public controllers
cake acl deny public controllers/MySecureController
cake acl deny public controllers/Widgets update
cake acl deny public controllers/Widgets delete
(the above is all done through the cake shell, but is easily translated to the PHP variant)
Basically, you can either use a "default-deny" paradigm (as demonstrated in Cake's own ACL tutorial), or a "default-allow" paradigm as above. Whichever method you choose will depend on how you expect the application to grow: will most of your controllers be public with only a select few restricted to Administrators, or will most of your application be restricted with Public given specific access where needed? Either way, you still need to either grant or deny access.
Notice the two AROs created under root: public and registered. With this model, treat registered as if it were root when creating your ARO tree -- put all of your "real user" groups underneath it. That way, you can use ACL as normal on the objects under registered, and the public users will exist outside of that.
All that said, there's nothing stopping you from using Cake's authentication mechanism and rolling your own access control method. Here's an example: Simple Authentication and Authorization Application. (NOTE: This is written for CakePHP 2.0, but the concepts apply to 1.3 as well).
EDIT -
After re-reading the question and the other responses, I realized you're aiming more for a role-based access control model rather than the traditional one-aro-per-user model of the builtin ACL component. Here are a couple of examples of extending the built-in auth component for RBAC:
Role-based ACL in CakePHP
CakePHP Auth component: Users, Groups, Permissions
Also, this two-part article describes an approach to database-backed role-based authorization that can be applied to your Cake application.
You can have both ACOs tree and AROs tree. In the AROs tree you will have adminsGroup<-usersGroup. You will need to setup rights for these groups. In the ACOs tree you will have baseACO<-subACO<-treeOfACOsForUsers. You will not need to maintain any new ACOs if: 1) userGroups are allowed to use subACO, 2) any new ACO is a child of subACO. The idea is to organize a tree of ACOs, so that if you allow access to a parent all children are accessable automatically. You can have a branch with denied access also. So you will need to maintain (assigning permissions) only several branches close to the root.
You may be interested to look at my PoundCake Control Panel - a plugin implementing ACL with user friendly web interface (CakePHP v1.3 is supported).
UPDATE:
Here is what you need.
I've inherited an app that makes heavy use of Cake's ACL -- a component I've never used -- and is configured such that 3 group AROs have access to an entire controller. ACOs exist for each action in the controller, but no permissions are explicitly assigned at the action level.
I've now run into a situation where I need one group to have access to one particular method, but I need to deny it for the other 2 groups. Is there any way to, rather than explicitly assigning permissions for each group to each action, simply indicate that the 2 groups do not have permissions to the one action in question?
Essentially, I want to keep the current "access to everything" default, but override that with a "deny for [this particular action]". I've tried cake bake acl deny GroupName ControllerName actionName, but that doesn't seem to have any impact.
By way of a fairly ubiquitous analogy, I'd like this to behave like Apache's AllowOverride. By default, allow everything to everyone, but deny a given action to a given group. I'm not sure whether that's helpful, but there it is.
Thanks.
This command will grant all your AROs access to your ACOs cake acl grant RootGroupName RootControllerName all.
Thereafter you can specify the particular actions you would like to deny access to: cake acl deny GroupName ControllerName|AcoActionName AcoActionName|permissions
If your second value after deny was an AcoActionName you would have to use one of the following values for permissions: all, create, read, update, delete.
A small tangent:
This is where I believe the confusion may lie. The structure of your
ACL [ACOs and AROs] are simply names of nodes that generally match the
structure of your controller/action setup, but can be called any name
your would like since the permissions are checked in each action. CakePHP ACLs organized in a
Tree (data structure) and the external nodes can have database level CRUD permissions set.
Here is a sample ACL schema for users and comments.
Aco tree:
---------------------------------------------------------------
[1] controllers (root node)
[2] Comments
[3] edit
[4] add
[5] delete
---------------------------------------------------------------
Aro tree:
---------------------------------------------------------------
[1] Groups (root node)
[2] Users
[3] Admin
---------------------------------------------------------------
Assuming access has been granted globally, all Requestors have access to all Objects. If you would like to deny Users from being able to edit comments once they have submitted them you would run cake acl deny Users Comments edit
Here is a great tutorial on ACLs, particularly the App_Controller code at the end which has a nice snippet that checks permissions for an ACO structure that matches controller/action: User Permissions and CakePHP ACL.
Additionally, the CakePHP Book has a nice snippet to insert all your controller/actions as ACO rules: An Automatic Tool for Creating ACOs