Chapitre 2. Zend_Acl

Table des matières

2.1. Introduction
2.1.1. A propos des Ressources
2.1.2. A propos des Rôles
2.1.3. Créer la Liste de Contrôle d'Accès (ACL)
2.1.4. Registre des Rôles
2.1.5. Définir les Contrôles d'Accès
2.1.6. Interroger les ACL
2.2. Affiner les Contrôles d'Accès
2.2.1. Mieux définir les Contrôles d'Accès
2.2.2. Retirer les Contrôles d'Accès
2.3. Utilisation avancée
2.3.1. Rendre les données ACL persistantes
2.3.2. Ecrire des règles ACL conditionnelle avec des assertions

2.1. Introduction

Zend_Acl fournit une solution légère et flexible de listes de contrôle d'accès (ACL : Access Control List), ainsi que la gestion de privilèges. En général, une application peut utiliser une telle fonctionnalité pour contrôler l'accès à certains objets par d'autres objets demandeurs.

Dans le cadre de cette documentation,

  • une Ressource est un objet dont l'accès est contrôlé

  • un Rôle est un objet qui peut demander l'accès à une Ressource.

Dit simplement, les Rôles demandent l'accès à des Ressources. Par exemple, si une personne demande l'accès à une voiture, alors la personne est le Rôle demandeur et la voiture est la Ressource, puisque l'accès à la voiture est soumis à un contrôle.

Grâce à la définition et à la mise en oeuvre d'une liste de contrôle d'accès (ACL), une application peut contrôler comment les objets demandeurs (Rôles) reçoivent l'accès (ou non) à des objets protégés (Ressources).

2.1.1. A propos des Ressources

Avec Zend_Acl, créer une Ressource est très simple. Zend_Acl fournit Zend_Acl_Resource_Interface pour faciliter la tâche aux développeurs. Une classe a simplement besoin d'implémenter cette interface, qui consiste en une seule méthode, getResourceId(), pour que Zend_Acl considère l'objet comme étant une Ressource. Par ailleurs, Zend_Acl_Resource est inclu dans Zend_Acl comme une implémentation basique de Ressource que les développeurs peuvent étendre si besoin.

Zend_Acl fournit une structure en arbre à laquelle plusieurs Ressources (ou "zone sous contrôle d'accès") peuvent être ajoutées. Puisque les Ressources sont sauvées dans cet arbre, elles peuvent être organisées du général (via la racine de l'arbre) jusqu'au particulier (via les feuilles de l'arbre). Les requêtes envers une Ressource spécifique vont automatiquement entraîner la recherche de règles sur ses parents au sein de la structure hiérarchique des Ressources, ce qui permet un héritage simple des règles. Par exemple, si une règle par défaut doit être appliquée à tous les batiments d'une ville, on pourra simplement assigner la règle à la ville elle-même, au lieu de la répéter à tous les batiments. Mais certains batiments peuvent nécessiter des règles spécifiques, et ceci peut se faire aisément avec Zend_Acl en assignant les règles nécessaires à chaque batiment de la ville qui nécessite une exception. Une Ressource peut hériter d'un seul parent Ressource, qui hérite lui même de son propre parent, et ainsi de suite.

Zend_Acl supporte aussi des privilèges pour chaque Ressources (e.g., "créer", "lire", "modifier", "supprimer"), et le développeur peut assigner des règles qui affectent tous les privilèges ou seuls certains privilèges d'une Ressource.

2.1.2. A propos des Rôles

Comme pour les Ressources, créer un Rôle est très simple. Zend_Acl propose Zend_Acl_Role_Interface pour faciliter le travail des développeurs. Une classe doit uniquement implémenter cette interface qui consiste en une seule méthode getRoleId(), pour que Zend_Acl considère l'objet comme un Rôle. De plus, Zend_Acl_Role est inclu dans Zend_Acl comme une implémentation basique de Rôle que les développeurs peuvent étendre si besoin.

Dans Zend_Acl, un Rôle peut hériter de un ou plusieurs Rôles. Ceci permet de supporter l'héritage de règles à travers plusieurs Rôles. Par exemple, un Rôle utilisateur, comme "eric", peut appartenir à un ou plusieurs Rôles d'action, tels que "éditeur" ou "administrateur". Le développeur peut créer des règles pour "éditeur" et "administrateur" séparément, et "eric" va hériter des règles des deux sans avoir à définir des règles directement pour "eric".

Bien que la possibilité d'hériter de plusieurs Rôles soit très utile, l'héritage multiple introduit aussi un certain degrè de complexité. L'example ci-dessous illustre l'ambiguïté et la manière de la résoudre.

Exemple 2.1. Héritages multiples entre Rôles

Le code ci-dessous définit trois Rôles de base - "invite", "membre", et "admin" - desquels d'autres Rôles peuvent hériter. Ensuite, un Rôle identifié par "unUser" est créé et hérite des trois autres Rôles. L'ordre selon lequel ces Rôles apparaissent dans le tableau $parents est important. Lorsque cela est nécessaire Zend_Acl recherche les règles d'accès définies non seulement pour le Rôle demandé (ici "unUser"), mais aussi pour les autres Rôles desquels le Rôle recherché hérite (ici "invite", "membre", et "admin"):

<?php
 require_once 'Zend/Acl.php';
 $acl = new Zend_Acl();
 
 require_once 'Zend/Acl/Role.php';
 $acl->addRole(new Zend_Acl_Role('invite'))
     ->addRole(new Zend_Acl_Role('membre'))
     ->addRole(new Zend_Acl_Role('admin'));
 
 $parents = array('invite', 'membre', 'admin');
 $acl->addRole(new Zend_Acl_Role('unUtilisateur'), $parents);
 
 require_once 'Zend/Acl/Resource.php';
 $acl->add(new Zend_Acl_Resource('uneResource'));
 
 $acl->deny('invite', 'uneResource');
 $acl->allow('membre', 'uneResource');
 
 echo $acl->isAllowed('unUtilisateur', 'uneResource') ? 'autorisé' : 'refusé';?>

Puisqu'il n'y a pas de règle spécifiquement définie pour le Rôle "unUser" et "uneResource", Zend_Acl doit rechercher des règles qui pourraient être définies pour des Rôles dont "unUser" hérite. Premièrement, le Rôle "admin" est contrôlé, et il n'y a pas de règle d'accès définie pour lui. Ensuite, le Rôle "membre" est visité, et Zend_Acl trouve qu'il y a une règle qui spécifie que "membre" a un accès autorisé à "uneResource".

Si Zend_Acl continuait à examiner toutes les règles de tous les Rôles parents, il trouverait que "invite" est interdit d'accès à "uneResource". Ceci introduit une ambiguité puisque maintenant "unUser" est à la fois autorisé et interdit d'accès à "uneResource", puisqu'il hérite de règles opposées de ses différents parents.

Zend_Acl résoud cette ambiguité en arrêtant la recherche de règles d'accès dès qu'une première règle est découverte. Dans notre exemple, puisque le Rôle "membre" est examiné avant le röle "invite", le résultat devrait afficher "autorisé".

[Note] Note

Lorsque vous spécifiez plusieurs parents pour un Rôle, conservez à l'esprit que le dernier parent listé est le premier dans lequel une règle utilisable sera recherchée.

2.1.3. Créer la Liste de Contrôle d'Accès (ACL)

Une ACL peut représenter n'importe quel ensemble d'objets physiques ou virtuels que vous souhaitez. Pour les besoins de la démonstration, nous allons créer un système basique d'ACL pour une Gestion de Contenus (CMS) qui comporte plusieurs niveaux de groupes au sein d'une grande variété de zones. Pour créer un nouvel objet ACL, nous créons une nouvelle instance de ACL sans paramètres:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();?>
[Note] Note

Jusqu'à ce que le développeur spécifie une règle "allow", Zend_Acl refuse l'accès pour tous les privilèges sur chaque ressource pour chaque rôle.

2.1.4. Registre des Rôles

Les systèmes de gestion de contenu vont pratiquement toujours nécessiter une hiérarchie de permissions afin de déterminer les droits de rédaction de ses utilisateurs. Il pourrait y avoir un groupe "Invités" qui donne accès aux démonstrations, un groupe "Staff" pour la majorité des utilisateurs du CMS qui réalisent la plupart du travail quotidien, un groupe "editeur" pour ceux qui sont responsables de la publication, l'archivage, la relecture et la suppression, et enfin un groupe "administrateur" dont les tâches incluent toutes les tâches des autres groupes plus des tâches de maintenance, de gestion des utilisateurs, configuration et backup/export. Cet ensemble de permissions peut être représenté dans un registre de Rôles, permettant à chaque groupe d'hériter des privilèges des groupes "parents". Les permissions peuvent être rendues de la manière suivante :

Tableau 2.1. Contrôles d'Accès pour un exemple de CMS

Nom Permissions Permissions héritées de
Invité Voir N/A
Staff Modifier, Soumettre, Relire Invité
Editeur Publier, Archiver, Supprimer Staff
Administrateur (Reçoit tous les accès) N/A

Pour cet exemple, Zend_Acl_Role est utilisé, mais n'importe quel objet qui implémente Zend_Acl_Role_Interface est acceptable. Ces groupes peuvent être ajoutés au registre des Rôles comme suit:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

// Ajoute des groupes au registre des Rôles en utilisant Zend_Acl_Role
require_once 'Zend/Acl/Role.php';

// Invité n'hérite d'aucun accès
$roleinvite = new Zend_Acl_Role('invite');
$acl->addRole($roleinvite);

// Staff hérite de Invité
$acl->addRole(new Zend_Acl_Role('staff'), $roleinvite);

/* Ce que précède pourrait aussi être écrit:
$roleinvite = $acl->addRole(new Zend_Acl_Role('staff'), 'invite');
//*/

// Editeur hérite de staff
$acl->addRole(new Zend_Acl_Role('editeur'), 'staff');

// Administrateur n'hérite pas d'accès
$acl->addRole(new Zend_Acl_Role('administrateur'));?>

2.1.5. Définir les Contrôles d'Accès

Maintenant que l'ACL contient les Rôles nécessaires, on peut établir des règles qui définissent comment les Ressources accèdent aux Rôles. Vous avez sans doute noté que nous n'avons défini aucune Ressource particulière pour cet exemple, ce qui est plus simple pour illustrer comment les règles s'appliquent à toutes les Ressources. Zend_Acl fournit une implémentation dans laquelle les règles doivent simplement être assignées du général au particulier, ce qui réduit le nombre de règles spécifiques à ajouter. Ceci grâce à l'héritage.

En conséquence, on peut définir un nombre assez complexe de règles avec un nombre minimal de code. Pour définir les permissions comme définies ci-dessus:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

require_once 'Zend/Acl/Role.php';

$roleinvite = new Zend_Acl_Role('invité');
$acl->addRole($roleinvite);
$acl->addRole(new Zend_Acl_Role('staff'), $roleinvite);
$acl->addRole(new Zend_Acl_Role('editeur'), 'staff');
$acl->addRole(new Zend_Acl_Role('administrateur'));

// Invité peut uniquement voir le contenu
$acl->allow($roleinvite, null, 'voir');

/* ce qui précède peut aussi être écrit:
$acl->allow('invité', null, 'voir');
//*/

// Staff hérite des privilèges de Invité, mais a aussi ses propres privilèges
$acl->allow('staff', null, array('edit', 'submit', 'relire'));

// Editeur hérite les privilèges voir, modifier, soumettre, et relire de Staff,
// mais a aussi besoin de certains privilèges
$acl->allow('editeur', null, array('publier', 'archiver', 'supprimer'));

// Administrateur hérite de rien, mais reçoit tous les privilèges
$acl->allow('administrateur');?>

Les valeurs null dans les appels allow() ci-dessus sont utilisées pour indiquer que les règles s'appliquent à toutes les Ressources.

2.1.6. Interroger les ACL

Nous avons maintenant un ACL flexible, qui peut être utilisé pour déterminer si l'objet appelant a les permissions pour réaliser les fonctions au sein de l'application web. Interroger l'ACL est assez simple en utilisant la méthode isAllowed():

<?php
echo $acl->isAllowed('invité', null, 'voir') ?
     "autorisé" : "refusé"; // autorisé

echo $acl->isAllowed('staff', null, 'publier') ?
     "autorisé" : "refusé"; // refusé

echo $acl->isAllowed('staff', null, 'relire') ?
     "autorisé" : "refusé"; // autorisé

echo $acl->isAllowed('editeur', null, 'voir') ?
     "autorisé" : "refusé"; // autorisé parce que hérité de Invité

echo $acl->isAllowed('editeur', null, 'modifier') ?
     "autorisé" : "refusé"; // refusé parce qu'il n'y a pas de règle pour 'modifier'

echo $acl->isAllowed('administrateur', null, 'voir') ?
     "autorisé" : "refusé"; // autorisé car administrateur est autorisé pour tout

echo $acl->isAllowed('administrateur') ?
     "autorisé" : "refusé"; // autorisé car administrateur est autorisé pour tout

echo $acl->isAllowed('administrateur', null, 'modifier') ?
     "autorisé" : "refusé"; // autorisé car administrateur est autorisé pour tout