Ce document propose l'analyse de base à la réalisation d'un système de gestion de droits (ACL = Access Control List). Les idées présentées ici ne sont en rien une généralisation de la façon de gérer des ACL mais bien une proposition subjective pour atteindre l'objectif ; à savoir, pouvoir contrôler suffisamment finement et le plus simplement possible l'accès à des opérations et des ressources dans une application, quelle qu'elle soit.
Les exemples et cas pratiques utilisés dans ce document sont rapportés à l'utilisation d'une ACL dans un CMS mais le concept peut être appliqué à tout autre support applicatif.
Je n'ai rien inventé dans tout ce qui va suivre et je m'inspire fortement de ce qui existe et de ce que j'ai pu trouver ça et là sur la toile mais l'écrire permet de fixer ma réflexion, d'en appréhender le fonctionnement et pourquoi pas d'en faire un outil que tout un chacun pourrait reprendre pour ses propres développements.
Document non définif et qui peut subir de profonds changements à tout moment !
Trois entités (deux au minimum) entrent en jeu pour réaliser un système de droits :
Tout droit est toujours au final appliqué à un utilisateur que ce soit pour un droit spécifiquement appliqué à ce dernier ou pour un droit appliqué à l'un des groupes auquel l'utilisateur appartient.
Pour simplifier le fonctionnement du système, il est préférable de ne prendre en considération que les groupes utilisateurs. Cela allège les ressources gérées dans la définition du droit et les traitements nécessaires au fonctionnement du système. L'astuce consiste à toujours créer un groupe utilisateurs du même nom que l'utilisateur, dans lequel il est le seul membre (de la même façon qu'un utilisateur UNIX appartient toujours à un groupe à son nom).
Dernier avantage, le fait de ne prendre en considération que les groupes utilisateurs dans le système de gestion de droit permet de rendre ce dernier aisément modulable et rattachable à une base utilisateurs existante.
Deuxième élément de base entrant dans la constitution d'un droit, le rôle représente une action fournie par l'application : créer une page, créer un article, modifier une page, supprimer un article, réindexer la base de données, éditer une catégorie, …
Dans l'ACL, le rôle est un simple libellé dont le contenu est totalement libre et dont la seule contrainte est que deux rôles ne peuvent avoir le même nom.
Exemple de nommage de rôle pour les différentes actions de base d'un CMS :
cms.page.create cms.page.update cms.page.delete cms.configuration.update blog.article.create ...
où la 1ère composante d'un rôle représenterait un module de l'application, la 2ème composante l'entité gérée par ce module et la dernière l'action réalisable sur l'entité.
Dernier élément non obligatoire mais nécessaire pour que la gestion des droits soit malléable et complète, la ressource représente les données volatiles créées et gérées par les utilisateurs de l'application (fichiers, pages, articles, images, …).
Le droit est donc l'association d'un rôle et d'un groupe d'utilisateurs. Si nécessaire, un droit peut être précisé pour une ressource.
Un droit = un rôle + un groupe d'utilisateurs OU Un droit = un rôle + un groupe d'utilisateurs + une ressource
Maintenant que nous avons les entités de base de notre système, étudions les règles de base qui lient tout ce petit monde :