Authentification d'utilisateurs dans Zend Framework

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.

  1. span style="color: #ff0000;">'guest'

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.

  1. span style="color: #ff0000;">'blogPost';
  2.     }
  3. }

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:

  1. span style="color: #808080; font-style: italic;">// mise en place des rôles
  2. $acl->addRole('guest');
  3. // owner hérite du rôle guest
  4. $acl->addRole('owner', 'guest');
  5.  
  6. // ajout de ressources
  7. $acl->addResource('blogPost');
  8.  
  9. // ajout de privilèges liant des rôles et des ressources
  10. $acl->allow('guest', 'blogPost', 'view');
  11. $acl->allow('owner', 'blogPost', 'post');
  12. $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:

  1. // Imaginons que le modèle User soit de type "guest"
  2. 'OwnersUsername''view'); // true
  3. 'view'); // true
  4. 'post'); // false
  5. '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:

  1. span style="color: #808080; font-style: italic;">/**
  2.      * Cette assertion va recevoir le User et le BlogPost actuels.
  3.      *
  4.      * @param Zend_Acl $acl
  5.      * @param Zend_Acl_Role_Interface $user
  6.      * @param Zend_Acl_Resource_Interface $blogPost
  7.      * @param $privilege
  8.      * @return bool
  9.      */'::'' s''
  10.                               . '');
  11.         }
  12.  
  13.         if (!$blogPost instanceof Default_Model_BlogPost) {
  14.             throw new Exception(__CLASS__
  15.                               . '::'
  16.                               . __METHOD__
  17.                               . ' s'attend à un rôle'
  18.                               . ' instance de BlogPost');
  19.         }
  20.  
  21.         // Si le rôle est publisher, il peut toujours modifier son billet
  22. 'publisher'// vérifions que qui que ce soit, il modifie uniquement ses propres billets

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

  1. // remplacez ceci:
  2. //   $acl->allow('owner', 'blogPost', 'publish');
  3. // par cela:
  4. $acl->allow('owner',
  5.             'blogPost',
  6.             'publish'// ajoutons aussi le rôle "publisher" qui a accès à tout
  7. $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.


Authentification d'utilisateurs dans Zend Framework