melbourne chapter

I thought I would discuss a quick overview on the structure to ACL for your applications. For initial background on ACL read this previous article first.

The implementation on ACL I have used in the past and appears in several different well known GNU applications is PHP Generic Access Control Lists (phpGACL). This library provides two main classes and an Administration Screen. The administration screen allows us a friendly way of managing our control lists, and the classes are used to check/modify them in our application. Overall I have found this package quite suitable for most situations.
Once installed, you will need to get familiar with the different terminology that is used.

First we must analyse the way that we need to set up our application. Typically we have many users with different group permissions. I like to use

- Developer
- Administrator
- Staff
- Public

These groups are groups of ARO or Access Request Objects. Therefore our 2Dimensional implementation is infact (ARO requests ACO). They are often the groups of system actors in your application, and represent the different objects/users making the requests. You can deal with groups of ARO’s or single ARO’s in your application. Your API calls will change slightly, my examples will explain as ARO groups.
How we manage the resources they wish to access can be either in a 2Dimensional (ARO requests this action) or 3D (ARO request this action on this object).

Both the ways of managing requires you to define our action/controlled object. These are called ACO or Access Controlled Objects. Typically I like to define a few sections of ACO’s, first being for the action being requested (in terms of MVC), and secondly any more fine-grained permissions, such as ‘Allow Edit’, ‘Allow Delete’, ‘Allow Hidden’ etc. Your ACO may end up being similar to:

Section: Actions
- login
- logout
- home
- documents
And another Section may manage specific more finegrained functionality on a particular operation:

Section: Documents
- edit
- add
- delete

In most situations this is more than enough for our small applications, and allows us to create well manageable applications, being able to create custom users/groups with specific permissions in our application, without requiring changes to our source code. As explained in my previous article, ACL allows us to make our security implementation extendable and manageable without requiring hundreds of updates to each of our source code files.

Now when we with to check a 2Dimensional request, we can do so with a simple ACL check; acl_check($resource, $group);

For our section ‘Actions’ I like to typically place this resource in our RequestProcessor, allowing us to have a ‘gatekeeper’ to whether the requested action can be performed by the current logged in user. This will ensure that every action is checked against the users permissions, before loading the Action to perform.

Our section ‘Documents’ would call specific checks to whether the user is allowed to perform a certain action in our Action class through again another set of ACL checks.

This situation becomes more complex when with have specific resources that the user wishes to manage, such as documents in a specific project. This becomes a 3Dimensional implementation that is when our ACO requests an ARO on a particular object. Yes I understand we are talking Object requests Object on an Object, and can come a bit complex, but the best is with an example. The 3rd Object is termed a AXO, or Access eXtension Object.

our AXO Section may look as follows:

Section: Projects
- project 1
- project 2
- project 3

This now allows us to further split down our requests so that our Document Management actions can be specific for a user in a particular project. Our ACL check becomes a little more complex, with having to specify a 3rd level.

Overall this implementation allows us to start to secure down what actions can be performed by our application users. We need to be conscious now to over-allow or over-complex our application for users as it will just mean more testing, training and explaining. Remember, just having ACL’s in your application does not make it more secure unless you use them correctly. You must be conscious of breaking down permissions, correctly verifying users and ensuring that you don’t just grant everything in your application.