Getting Started with Zend_Session, _Auth, _Acl. Building an Authorization System in Zend Framework

Introduction to Authorization

After a user has been identified as being authentic, an application can go about its business of providing some useful and desirable resources to a consumer. In many cases, applications might contain different resource types, with some resources having stricter rules regarding access. This process of determining who has access to which resources is the process of "authorization". Authorization in its simplest form is the composition of these elements:

    • the identity whom wishes to be granted access

    • the resource the identity is asking permission to consume

    • and optionally, what the identity is privileged to do with the resource

In Zend Framework, the Zend_Acl component handles the task of building a tree of roles, resources and privileges to manage and query authorization requests against.

Basic Usage of Zend_Acl

When using Zend_Acl, any models can serve as roles or resources by simply implementing the proper interface. To be used in a role capacity, the class must implement the Zend_Acl_Role_Interface, which requires only getRoleId(). To be used in a resource capacity, a class must implement the Zend_Acl_Resource_Interface which similarly requires the class implement the getResourceId() method.

Demonstrated below is a simple user model. This model can take part in our ACL system simply by implementing the Zend_Acl_Role_Interface. The method getRoleId() will return the id "guest" when an ID is not known, or it will return the role ID that was assigned to this actual user object. This value can effectively come from anywhere, a static definition or perhaps dynamically from the users database role itself.

  01. class Default_Model_User implements Zend_Acl_Role_Interface

  02. {

  03.     protected $_aclRoleId = null;

  04.  

  05.     public function getRoleId()

  06.     {

  07.         if ($this->_aclRoleId == null) {

  08.             return 'guest';

  09.         }

  10.  

  11.         return $this->_aclRoleId;

  12.     }

  13. }

While the concept of a user as a role is pretty straight forward, your application might choose to have any other models in your system as a potential "resource" to be consumed in this ACL system. For simplicity, we'll use the example of a blog post. Since the type of the resource is tied to the type of the object, this class will only return 'blogPost' as the resource ID in this system. Naturally, this value can be dynamic if your system requires it to be so.

  01. class Default_Model_BlogPost implements Zend_Acl_Resource_Interface

  02. {

  03.     public function getResourceId()

  04.     {

  05.         return 'blogPost';

  06.     }

  07. }

Now that we have at least a role and a resource, we can go about defining the rules of the ACL system. These rules will be consulted when the system receives a query about what is possible given a certain role, resources, and optionally a privilege.

Lets assume the following rules:

  01. $acl = new Zend_Acl();

  02.  

  03. // setup the various roles in our system

  04. $acl->addRole('guest');

  05. // owner inherits all of the rules of guest

  06. $acl->addRole('owner', 'guest');

  07.  

  08. // add the resources

  09. $acl->addResource('blogPost');

  10.  

  11. // add privileges to roles and resource combinations

  12. $acl->allow('guest', 'blogPost', 'view');

  13. $acl->allow('owner', 'blogPost', 'post');

  14. $acl->allow('owner', 'blogPost', 'publish');

The above rules are quite simple: a guest role and an owner role exist; as does a blogPost type resource. Guests are allowed to view blog posts, and owners are allowed to post and publish blog posts. To query this system one might do any of the following:

  01. // assume the user model is of type guest resource

  02. $guestUser = new Default_Model_User();

  03. $ownerUser = new Default_Model_Owner('OwnersUsername');

  04.  

  05. $post = new Default_Model_BlogPost();

  06.  

  07. $acl->isAllowed($guestUser, $post, 'view'); // true

  08. $acl->isAllowed($ownerUser, $post, 'view'); // true

  09. $acl->isAllowed($guestUser, $post, 'post'); // false

  10. $acl->isAllowed($ownerUser, $post, 'post'); // true

As you can see, the above rules exercise whether owners and guests can view posts, which they can, or post new posts, which owners can and guests cannot. But as you might expect this type of system might not be as dynamic as we wish it to be. What if we want to ensure a specific owner actual owns a very specific blog post before allowing him to publish it? In other words, we want to ensure that only post owners have the ability to publish their own posts.

This is where assertions come in. Assertions are methods that will be called out to when the static rule checking is simply not enough. When registering an assertion object this object will be consulted to determine, typically dynamically, if some roles has access to some resource, with some optional privlidge that can only be answered by the logic within the assertion. For this example, we'll use the following assertion:

  01. class OwnerCanPublishBlogPostAssertion implements Zend_Acl_Assert_Interface

  02. {

  03.     /**

  04.      * This assertion should receive the actual User and BlogPost objects.

  05.      *

  06.      * @param Zend_Acl $acl

  07.      * @param Zend_Acl_Role_Interface $user

  08.      * @param Zend_Acl_Resource_Interface $blogPost

  09.      * @param $privilege

  10.      * @return bool

  11.      */

  12.     public function assert(Zend_Acl $acl,

  13.                            Zend_Acl_Role_Interface $user = null,

  14.                            Zend_Acl_Resource_Interface $blogPost = null,

  15.                            $privilege = null)

  16.     {

  17.         if (!$user instanceof Default_Model_User) {

  18.             throw new Exception(__CLASS__

  19.                               . '::'

  20.                               . __METHOD__

  21.                               . ' expects the role to be'

  22.                               . ' an instance of User');

  23.         }

  24.  

  25.         if (!$blogPost instanceof Default_Model_BlogPost) {

  26.             throw new Exception(__CLASS__

  27.                               . '::'

  28.                               . __METHOD__

  29.                               . ' expects the resource to be'

  30.                               . ' an instance of BlogPost');

  31.         }

  32.  

  33.         // if role is publisher, he can always modify a post

  34.         if ($user->getRoleId() == 'publisher') {

  35.             return true;

  36.         }

  37.  

  38.         // check to ensure that everyone else is only modifying their own post

  39.         if ($user->id != null && $blogPost->ownerUserId == $user->id) {

  40.             return true;

  41.         } else {