• Authorize access to a model’s method
• Authorize access to a controller action
• Authorize access to an arbitrary “permission”

In general I find it’s best to keep authorization within the domain (querying the ACL within my models when they’re accessed) as this provides the most consistent behavior.  For example, if I eventually add a REST API to my application I don’t have to duplicate all my authorization logic in the new REST controllers.  When the application calls something like Default_Model_Post::save() it either saves or throws an ACL exception, no matter where it was called from.  This is great in that it saves me from having to duplicate code and keeps my system more secure.

On the other hand, there are times when it’s just a lot easier to handle authorization in the controller.  For example, if guests should never access my “Admin” module, it doesn’t make sense to ever let them access /admin/ URLs.  Also, if you’re using Zend_Navigation, having ACL resources that match controller actions lets you utilize its ACL integration.

If you’re ever going to mix these two techniques, you’ll eventually bump into the case where a model and a controller share the same name.  What if you need to set permissions on a “user” controller and different permissions on a “user” model?  This is where namespacing comes into play.  As suggested by the Zend Framework manual, I always name my controller action resources in the format mvc:module.controller.action.  I name my model resources similarly, in the format model:module.modelName.methodName.  In both theses cases, “mvc” and “model” are the namespace, and everything following the colon is the actual resource name.  Now I can refer to my “admin” module as mvc:admin and the models within my admin module as model:admin.

This is where things get interesting.  If you set up your ACL chains correctly, you can set permissions on whole modules or models and have those rules cascade to their child controllers or methods.  For example, say you set up your ACL as follows:

$acl = new Zend_Acl();
$acl->addResource('mvc:');
$acl->addResource('mvc:admin', 'mvc:');
$acl->addResource('mvc:admin.user', 'mvc:admin');
$acl->addResource('mvc:admin.user.create', 'mvc:admin.user');
$acl->addRole('guest');
$acl->addRole('admin', 'guest');
$acl->deny();
$acl->allow('admin', 'mvc:admin');

Now if a user with the role “admin” tries to access the resource “mvc:admin.user.create” (http://basename/admin/user/create) they will be allowed, but a user with the role “guest” will not.  Using this technique gives you as much granularity as you need in your ACL, but at the same time lets you set broad permissions where appropriate.

This is where Galahad_Acl comes into play.  Setting up all these resources can be tedious, as is checking permissions in each controller.  Galahad_Acl in conjunction with Galahad_Model_Entity and Galahad_Controller_Plugin_Acl automate everything but the actual permissions that are specific to your application.

By default, whenever Galahad_Acl has a role added to it in the format “namespace:resource.subResourse” (etc) it automatically adds the resources up the chain.  For example, if I add “mvc:default.index.index” to a Galahad_Acl object, it would add the following resources to the ACL:

• mvc:
• mvc:default (parent = “mvc:”)
• mvc:default.index (parent = “mvc:default”)
• mvc:default.index.index (parent = “mvc:default.index”)

Galahad_Controller_Plugin_Acl takes this a step further by automatically adding any controller action that’s dispatched to the ACL and then checking against the ACL.  This means that with the following ACL:

$acl = new Galahad_Acl();
$acl->addRole('guest');
$acl->addRole('staff', 'guest');
$acl->addRole('admin', 'staff');
$acl->addResource('mvc:blog.entry.view');
$acl->deny();
$acl->allow('admin', 'mvc:');
$acl->allow('staff', 'mvc:blog');
$acl->allow('guest', 'mvc:blog.entry.view');

The following would be true:

• Role “admin” would be allowed access to any URL (“admin” is allowed access to “mvc:”)
• Role “staff” would be allowed access to /blog/entry/edit even though permissions weren’t explicitly set for the resource “mvc:blog.entry.edit” (because “staff” is allowed to access “mvc:blog”)
• Role “guest” would be allowed to view /blog/entry/view but no other portion of the blog (“guest” is allowed access to the specific resource “mvc:blog.entry.view”)

Galahad_Model_Entity works similarly.  By default each entity adds itself to the ACL in the format “model:module.modelName” so that the model Default_Model_User has the resource ID “model:default.user”.  Each model has a method called _initAcl which lets you manage permissions on a per-model basis.  This is better demonstrated in code:

class Default_Model_Post extends Galahad_Model_Entity
{
    protected function _initAcl($acl)
    {
        // Deny permissions to anything on this model unless explicitly allowed
        // We don't have to add "model:default.post" because Galahad_Model_Entity
        // automatically does that for us
        $acl->deny(null, $this);
        // Allow guests to fetch the content of posts
        $acl->allow('guest', $this, 'fetch')
        // Allow admins to save changes to posts
        $acl->allow('admin', $this, 'save')
    }
    public function save()
    {
        if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
            throw new Galahad_Acl_Exception('Current user is not allowed to save posts');
        }
        $dataMapper = $this->getDataMapper();
        return $dataMapper->save($this);
    }
}

So, as you can see, the model denies access to itself unless explicitly allowed, and then allows access to certain methods for certain roles.

All three of these classes are in their early stages of development, but I’d love some feedback on the ideas/suggestions on how to make them better.

Check out the code on GitHub:

• Galahad_Acl
• Galahad_Controller_Plugin_Acl
• Galahad_Model_Entity

Also, for more information about the Galahad_Model system, check out my previous post on modeling in the Zend Framework.