Fabriquer un système de gestion d'autorisations avec Zend Framework

Introduction à l'autorisation

Après qu'un utilisateur se soit authentifié, une application peut proposer différentes règles d'accès à ses différentes ressources (parties). Le procédé qui consiste à savoir "qui a le droit de faire quoi" est nommé "gestion des autorisations". Dans sa forme la plus simple l'autorisation est la composition de trois facteurs:

l'identitié de la personne souhaitant des droits - le rôle (qui?)
la ressource demandée (sur quoi?)
et optionnellement le privilège - le droit (quoi?)

Dans Zend Framework, le composant Zend_Acl vous propose de créer ces trois entités remarquables, de les associer et de les interroger dans le futur.

Utilisation de base de Zend_Acl

En utilisant Zend_Acl, n'importe quel modèle peut servir de rôle ou de ressource en implémentant l'interface adéquate. Pour créer des rôles, implémentez Zend_Acl_Role_Interface, qui définit la méthode getRoleId(). Pour créer des ressources, implémentez Zend_Acl_Resource_Interface qui définit la méthode getResourceId().

Nous allons faire une démonstration avec un modèle simple. On peut le relier avec notre système d'ACL en implémentant Zend_Acl_Role_Interface. La méthode getRoleId() retournera "guest" lorsque l'ID est inconnu, ou l'ID du rôle lorsque celui-ci aura été affecté. Cette valeur peut provenir de n'importe où, probablement qu'elle proviendra d'une définition faite en base de données.

class Default_Model_User implements Zend_Acl_Role_Interface
{
    protected $_aclRoleId = null;
 
    public function getRoleId()
    {
        if ($this->_aclRoleId == null) {
            return 'guest';
        }
 
        return $this->_aclRoleId;
    }
}

Le concept des utilisateurs ayant des rôles est simple à comprendre, mais l'application peut consommer plusieurs modèles et en retrouver des "ressources" qui seront consommables par les rôles. Nous utiliserons simplement des billets de blog comme ressources dans nos exemples, et comme les ressources sont des objets, nous ferons en sorte que l'ID d'un billet blog soir 'blogPost', naturellement cette valeur peut être calculée dynamiquement en fonction du besoin.

class Default_Model_BlogPost implements Zend_Acl_Resource_Interface
{
    public function getResourceId()
    {
        return 'blogPost';
    }
}

Maintenant que nous avons au minimum un rôle et une ressource, définissons règles qui les lient. Ces règles seront lues lorsque le système recevra une requête d'acl demandant ce qu'il est possible de faire avec tel rôle, telle ressource et éventuellement tel privilège.

Imaginons les règles suivantes:

$acl = new Zend_Acl();
 
// mise en place des rôles
$acl->addRole('guest');
// owner hérite du rôle guest
$acl->addRole('owner', 'guest');
 
// ajout de ressources
$acl->addResource('blogPost');
 
// ajout de privilèges liant des rôles et des ressources
$acl->allow('guest', 'blogPost', 'view');
$acl->allow('owner', 'blogPost', 'post');
$acl->allow('owner', 'blogPost', 'publish');

Les règles ci-dessus sont très simples: deux rôles "guest"(invité) et "owner" (propriétaire), et une ressource "blogPost"(billet). Les invités sont autorisés à voir les billets, les propriétaires peuvent poster et publier des billets. Pour requêter le système, procédez alors comme suit:

// Imaginons que le modèle User soit de type "guest"
$guestUser = new Default_Model_User();
$ownerUser = new Default_Model_Owner('OwnersUsername');
 
$post = new Default_Model_BlogPost();
 
$acl->isAllowed($guestUser, $post, 'view'); // true
$acl->isAllowed($ownerUser, $post, 'view'); // true
$acl->isAllowed($guestUser, $post, 'post'); // false
$acl->isAllowed($ownerUser, $post, 'post'); // true

Comme vous pouvez le voir le système répond comme il faut dans la mesure où les invités peuvent lire les billets mais seuls les propriétaires peuvent en ajouter. Cependant ce système peut sembler manquer de dynamisme. Comment vérifier qu'un utilisateur spécifique est bien propriétaire d'un billet spécifique avant de l'autoriser à le publier ? Autrement dit, on veut s'assurer que seuls les propriétaires des billets peuvent publier ceux-ci, et pas ceux des autres.

C'est là qu'entrent en jeu les assertions. Les assertions sont des vérifications supplémentaires à effectuer en même temps que la vérification de la règle d'acl. Ce sont des objets. Utilisons notre exemple avec une assertion:

class OwnerCanPublishBlogPostAssertion implements Zend_Acl_Assert_Interface
{
    /**
     * Cette assertion va recevoir le User et le BlogPost actuels.
     *
     * @param Zend_Acl $acl
     * @param Zend_Acl_Role_Interface $user
     * @param Zend_Acl_Resource_Interface $blogPost
     * @param $privilege
     * @return bool
     */
    public function assert(Zend_Acl $acl,
                           Zend_Acl_Role_Interface $user = null,
                           Zend_Acl_Resource_Interface $blogPost = null,
                           $privilege = null)
    {
        if (!$user instanceof Default_Model_User) {
            throw new Exception(__CLASS__
                              . '::'
                              . __METHOD__
                              . ' s'attend à un rôle'
                              . ' instance de User');
        }
 
        if (!$blogPost instanceof Default_Model_BlogPost) {
            throw new Exception(__CLASS__
                              . '::'
                              . __METHOD__
                              . ' s'attend à un rôle'
                              . ' instance de BlogPost');
        }
 
        // Si le rôle est publisher, il peut toujours modifier son billet
        if ($user->getRoleId() == 'publisher') {
            return true;
        }
 
        // vérifions que qui que ce soit, il modifie uniquement ses propres billets
        if ($user->id != null && $blogPost->ownerUserId == $user->id) {
            return true;
        } else {
            return false;
        }
    }
}

Pour faire intervenir l'assertion dans les ACL, nous les utilisons comme ceci:

// remplacez ceci:
//   $acl->allow('owner', 'blogPost', 'publish');
// par cela:
$acl->allow('owner',
            'blogPost',
            'publish',
            new OwnerCanPublishBlogPostAssertion());
 
// ajoutons aussi le rôle "publisher" qui a accès à tout
$acl->allow('publisher', 'blogPost', 'publish');

Maintenant, dès que l'ACL est consultée pour savoir si un propriétaire peut publier un billet, cette assertion sera vérifiée. Elle s'assure que sauf si le rôle est 'publisher' le propriétaire a bien écrit le billet. Dans cet exemple, nous vérifions pour savoir si l'attribut ownerUserId du billet correspond à l'identifiant de l'utilisateur en question.