Question

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.

Answer 1

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.