Différences

Ci-dessous, les différences entre deux révisions de la page.

--- conception:acl [2009/04/29 18:04] – samray1024
+++ conception:acl [2024/10/03 07:26] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+====== Concevoir un système de gestion de droits ======
+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. //
+FIXME Document non définif et qui peut subir de profonds changements à tout moment !
+===== Concepts =====
+Trois entités (deux au minimum) entrent en jeu pour réaliser un système de droits :
+  - Un utilisateur ou un groupe d'utilisateurs
+  - Un rôle
+  - Une ressource (non obligatoire)
+==== Groupe d'utilisateurs ====
+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.
+==== Rôle ====
+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é.
+==== Ressource ====
+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, ...).
+==== Droit ====
+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
+===== Règles =====
+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 :
+  - Un utilisateur fait partie d'au moins un groupe d'utilisateurs du même nom, dans lequel il est seul.
+  - Ce groupe d'utilisateurs est un groupe privé et aucun autre utilisateur ne pourra y être affecté.
+  - Un groupe d'utilisateurs peut être marqué comme par défaut. Cela permet d'affecter automatiquement un utilisateur aux groupes par défaut lors de sa création.
+  - Un groupe d'utilisateurs peut être privé ou public.
+  - Un groupe d'utilisateurs privé ne peut être associé à aucun utilisateur. Il servira uniquement de groupe de définition de droits dans le cadre de l'héritage (explications dans un instant ;-)).
+  - Un groupe d'utilisateurs peut (ou pas) hériter d'un ou plusieurs autres groupes.
+  - Les groupes utilisateurs sont pondérés de sorte qu'un groupe d'une pondération plus faible qu'un autre est alors reconnu comme étant de niveau supérieur. Toutes les autorisations concédées à un groupe d'un certain niveau sont valables sur les groupes de plus faible niveau.
+  - Un rôle peut être associé à autant de groupes que nécessaires.
+  - Un utilisateur possède toujours tous les droits sur les ressources pour lesquelles il est propriétaire (il n'est donc pas nécessaire de créer des entrées dans l'ACL pour ses ressources).
+  - Toute ressource appartenant à un autre utilisateur est accessible par un autre utilisateur si :
+    - L'utilisateur non propriétaire est dans un groupe associé à un rôle qui l'autorise à accéder à d'autres ressources que les siennes (lien groupe d'utilisateurs + rôle),
+    - L'utilisateur non propriétaire possède une autorisation spéciale sur la ressource (lien groupe d'utilisateurs + rôle + ressource).
+  - L'utilisateur d'un groupe ne peut accéder aux ressources d'un autre utilisateur si ce dernier est dans le même groupe, même si la définition de ce groupe lui en donne théoriquement le droit. Pour en avoir le droit sans demander l'autorisation au propriétaire, il est nécessaire d'être dans un groupe de plus haut niveau (= de plus faible pondération). Ce groupe doit bien entendu être associé à un rôle permettant l'accès à la ressource. (__Exemple :__ deux modérateurs peuvent modérer les ressources de redacteurs mais ne peuvent pas se modérer entre eux).
+==== Héritage des groupes d'utilisateurs ====