Gestion des ACL avec le Zend Framework

Gestion des ACL avec le Zend Framework

Zend_Acl est le composant du Zend Framework pour la gestion de listes des contrôle d’accès. Son implémentation se veut être légère et flexible. En général, une application peut utiliser une telle fonctionnalité pour contrôler l’accès à certains objets par d’autres objets demandeurs.

Il y a 2 notions à savoir pour comprendre les ACL dans le Zend Framework :

Ressources

D’un point de vue développement, une ressource est simplement un objet dont la classe implémente l’interface Zend_Acl_Resource_Interface. Elle est composé d’une seule méthode

getResourceId()
. Comme souvent dans ce framework, il existe une implémentation basique : Zend_Acl_Resource. Libre à chaque développeur de l’étendre.

Les ressources sont organisés dans une arborescence. Les règles les plus générales sont affectés à la racine de l’arbre, les plus spécifiques correspondent aux feuilles. On a donc affaire à un héritage simple des ressources. Zend_Acl supporte aussi des privilèges pour chaque ressource (par exemple : “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.

Rôles

A l’instar des ressources, les rôles ont une structure similaire à savoir : une interface Zend_Acl_Role_Interface qui définit la méthode

getRoleId()
et une implémentation basique Zend_Acl_Role que l’on peut étendre. Par contre, 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.

L’exemple d’un CMS

Prenons l’exemple d’un CMS simpliste où les règles régissant les droits sont définis dans le tableau suivant.



Identifiant Description Permissions Permissions héritées de
anonyme Utilisateur lambda qui navigue sur le site
Article
voir
Rédacteur Utilisateur pouvant se connecté sur le backoffice et écrire, modifier des articles sans les publier
Backoffice
connecter
Article
creer
modifier
voir
anonyme
Modérateur Utilisateur disposant des mêmes droits qu’un rédacteur mais capable en plus de publier un article et de le supprimer
Backoffice
connecter
Article
creer
modifier
voir
publier
supprimer
redacteur
Admnistrateur Utilisateur disposant de tous les droits. Tous les droits

A partir de ces éléments, on identifie clairement les différentes ressources: article et backoffice, les différents rôles (anonyme, redacteur, moderateur et admnistrateur) et on voit les différentes règles d’héritage.

Implémentation dans le Zend Framework

Définition des droits

Création des listes de contrôles d’accès (ACL)
$acl = new Zend_Acl();
Ajouts des ressources
$acl->add(new Zend_Acl_Resource('backoffice'));$acl->add(new Zend_Acl_Resource('article'));
Configuration des rôles
$acl->addRole(new Zend_Acl_Role('anonyme'));
$acl->addRole(new Zend_Acl_Role('redacteur'), 'anonyme');
$acl->addRole(new Zend_Acl_Role('moderateur'), 'redacteur');
$acl->addRole(new Zend_Acl_Role('administrateur'));
Définition des règles de gestions
$acl->allow('anonyme', 'article', 'voir');
// Rédacteur hérite des règles de anonyme mais à aussi ses propres règles
$acl->allow('redacteur', 'backoffice', 'connecter');$acl->allow('redacteur', 'article', array('creer','modifier'));
// Modérateur hérite des règles de rédacteur mais à aussi ses propres règles
$acl->allow('moderateu', 'article', array('modifier', 'publier', 'supprimer'));
// Admninistrateur à tous les droits
$acl->allow('admninistrateur');

Comme souvent dans le Zend Framework, il faut moins de code que de spécification pour avoir un programme fonctionnel.

Interrogation

L’interrogation des ACL est encore plus simple que leurs déclaration. Voici 2 exemples :

echo $acl->isAllowed(‘anonyme’, ‘article’, ‘modifier’) ? \“autorisé\” : \“refusé\“;
echo $acl->isAllowed(‘administrateur’, null, ‘voir’) ? \“autorisé\” : \“refusé\“;

Concepts avancés

Persistances des ACL

Zend Framework n’impose pas de solution pour la persistance des ACL. Il est très facile et très rapide de mettre en place des stockages soit en base de données, soit en cache, soit dans un fichier sérialisé avec les différents composants du framework. Libre à chaque développeur de choisir la méthode qui conviendra le mieux à son environnement, à son projet.

Règles conditionnelles

Dans notre exemple, toutes les règles de gestions sont connus et et déterminées à l’avance. Certaines situations exigent que l’on puissent avoir des règles plus complexes. Pour cela le Zend Framework fournit une interface Zend_Acl_Assert_Interface, dans laquelle il suffit d’implémenter la méthode assert().

class CleanIPAssertion implements Zend_Acl_Assert_Interface {  
    
    public function assert(
        Zend_Acl $acl, 
        Zend_Acl_Role_Interface $role = null, 
        Zend_Acl_Resource_Interface $resource = null, 
        $privilege = null)  {    
        return $this->_isCleanIP($_SERVER['REMOTE_ADDR']);  
    }  
    
    protected function _isCleanIP($ip)  {    
        //...  
    }
}

Pour vérifier que l’assertion que l’on vient de définir est valide, on utilise exactement le même code qu’auparavant.

$acl = new Zend_Acl();
$acl->allow(null, null, null, new CleanIPAssertion());

Le code ci-dessus crée une règle conditionnelle qui autorise l’accès à tous les privilèges, sur tout et pour tout le monde, sauf lorsque l’adresse IP de la requête fait partie de la liste noire. La règle s’applique à tous les rôles, toutes les ressources, et tous les privilèges, une IP ne passant pas l’assertion entrainera un accès refusé.Le composant fournit par le Zend Framework pour la gestion des droits est puissant et flexible. Il est indépendant du reste du framework, mais on peut facilement le combiner avec d’autres composants pour gérer par exemple le stockage.

comments powered by Disqus
A la une
  • Rencontre du numérique 2019 - Nîmes
  • référencement naturel d'un hôtel
  • Développeur eZ Platform
  • Tech lead Symfony
  • Expert Qualité Web

Copyright - Sylvain FIX

2009 - 2019