Welcome to the Cookbook

loading...

5.1.1 Comprendre comment les ACL fonctionnent

Les choses puissantes requièrent un contrôle d'accès. Les listes de contrôles d'accès sont une façon de gérer les permissions d'une application d'une manière très précise et pourtant facilement maintenable et manipulable.

Les listes de contrôles d'accès, ou ACL (Access Control Lists), manipulent deux choses principales : les choses qui veulent accéder à des trucs et celles qui sont recherchées. Dans le jargon ACL, les choses qui veulent accéder à des trucs (le plus souvent les utilisateurs) sont appelées access request objects (objets requête d'accès) ou AROs. Les choses du système qui sont recherchées (le plus souvent les actions ou les données) sont appelées access control objects (objets contrôle d'accès) ou ACOs. Les entités sont appelées "objets", parce que parfois, l'objet demandé n'est pas une personne - des fois, vous pourriez vouloir limiter l'accès à certains contrôleurs de Cake qui doivent initier leur logique dans d'autres parties de votre application. Les ACOs pourraient être n'importe quoi que vous voudriez contrôler, d'une action de contrôleur à un service Web, en passant par une case de l'agenda en ligne de votre Mamy.

Rappel :

  • ACO - Objet Contrôle d'Accès - Quelque chose qui est recherchée
  • ARO - Objet Requête d'Accès - Quelque chose qui veut quelque chose

Généralement, les ACL sont utilisées pour décider quand un ARO peut obtenir l'accès à un ACO.

Afin de vous aider à comprendre comment toutes les choses travaillent ensemble, utilisons un exemple semi-fonctionnel. Imaginons un moment, un ordinateur utilisé par un célèbre groupe d'aventuriers tirés du roman fantastique le Seigneur des Anneaux. Le chef du groupe, Gandalf, veut gérer les biens du groupe, tout en maintenant un bon niveau de confidentialité et de sécurité entre les autres membres de l'équipe. La première chose dont il a besoin est de créer une liste d'AROs qui comprend :

  • Gandalf
  • Aragorn
  • Bilbo
  • Frodo
  • Gollum
  • Legolas
  • Gimli
  • Pippin
  • Merry

Comprenez que l'ACL n'est pas la même chose que l'authentification. L'ACL est ce qui vient après qu'un utilisateur ait été authentifié. Par contre, les deux sont habituellement utilisés de paire, il est important de faire la distinction entre savoir qui est quelqu'un (authentification) et savoir ce qu'il peut faire (ACL).

La chose suivante que Gandalf doit faire, c'est de créer une liste initiale des choses, ou ACOs, que le système va contrôler. Sa liste devrait ressembler à quelque chose comme ça :

  • Les armes
  • L'Anneau
  • Le porc salé
  • La diplomatie
  • La bière

Traditionnellement, les systèmes étaient gérés en utilisant une sorte de matrice, qui présentait un ensemble basique d'utilisateurs et de permissions en relation avec les objets. Si ces informations étaient stockées dans un tableau, il ressemblerait à ça :

Les armes L'Anneau Le porc salé La diplomatie La bière
Gandalf Autorisé Autorisé Autorisé
Aragorn Autorisé Autorisé Autorisé Autorisé
Bilbo Autorisé
Frodo Autorisé Autorisé
Gollum Autorisé
Legolas Autorisé Autorisé Autorisé Autorisé
Gimli Autorisé Autorisé
Pippin Autorisé Autorisé
Merry Autorisé

A première vue, il semble que ce système pourrait très bien fonctionner. Les affectations peuvent être mises en place à des fin de sécurité (seul Frodo peut accéder à l'Anneau) et pour éviter les accidents (en gardant les hobbits à distance du porc salé et des armes). Cela paraît suffisamment complet et assez facile à lire, n'est-ce pas ?

Pour un petit système comme celui-ci, peut-être qu'une configuration en matrice pourrait fonctionner. Mais pour un système évolutif ou un système avec un fort pourcentage de ressources (ACOs) et d'utilisateurs (AROs), un tableau peut devenir plus lourd que rapide. Imaginez une tentative de contrôler l'accès à des centaines de camps militaires et de gérer cela par unité. Un autre inconvénient des matrices est que vous ne pouvez par vraiment regrouper logiquement des sections d'utilisateurs ou faire des changements de permissions en cascade, pour des groupes d'utilisateurs basés sur ces regroupements logiques. Par exemple, il serait certainement plus chouette d'autoriser automatiquement les hobbits à accéder à la bière et au porc une fois que le combat est fini : faire ça sur une base d'utilisateurs gérés individuellement pourrait être fastidieux et source d'erreur. Faire des changements de permissions en cascade pour tous les "hobbits" serait plus facile.

Les ACL sont très souvent implémentés dans une structure en arbre. Il y a généralement un arbre d'AROs et un arbre d'ACOs. En organisant vos objets en arbres, les permissions peuvent toujours être distribuées d'une façon granulaire, tout en maintenant encore une bonne cohérence de l'ensemble. En chef raisonnable qu'il est, Gandalf choisit d'utiliser l'ACL dans son nouveau système et d'organiser ses objets de la manière suivante :

  • La Communauté de l'Anneau™
    • Les Guerriers
      • Aragorn
      • Legolas
      • Gimli
    • Les Magiciens
      • Gandalf
    • Les Hobbits
      • Frodo
      • Bilbo
      • Merry
      • Pippin
    • Les Visiteurs
      • Gollum

L'utilisation d'une structure en arbre pour les AROs permet à Gandalf, de définir en une fois des autorisations qui s'appliquent à un groupe entier d'utilisateurs. Ainsi, en utilisant notre arbre ARO, Gandalf peut ajouter, après coup, quelques permissions de groupe :

  • La Communauté de l'Anneau
    (Refuser : tout)
    • Guerriers
      (Autoriser : Armes, Bière, Rations pour les Elfes, Porc salé)
      • Aragorn
      • Legolas
      • Gimli
    • Magiciens
      (Autoriser : Porc salé, Diplomatie, Bière)
      • Gandalf
    • Hobbits
      (Autoriser : Bière)
      • Frodo
      • Bilbo
      • Merry
      • Pippin
    • Visiteurs
      (Autoriser : Porc salé)
      • Gollum

Si nous voulions utiliser les ACL pour voir si Pippin était autorisé à accéder à la bière, nous devrions d'abord récupérer son chemin dans l'arbre, lequel est Communauté->Hobbits->Pippin. Ensuite nous verrions les différentes permissions qui résident à chacun de ces points et nous utiliserions la plus spécifique des permissions reliant Pippin et la bière.

Nœud de l'ARO Information sur la permission Résultat
La Communauté de l'Anneau Refuse tout Refuser l'accès à la bière.
Les Hobbits Autorise la bière Autoriser l'accès à la bière !
Pippin -- Toujours autoriser la bière !

Puisque le nœud "Pippin" dans l'arbre d'ACL ne refuse pas spécifiquement l'accès à l'ACO bière, le résultat final est que nous donnons l'accès à cet ACO.

L'arbre nous permet aussi de faire des ajustements plus fins pour un meilleur contrôle granulaire, tout en conservant encore la capacité de faire de grands changements pour les groupes d'AROs :

  • Communauté de l'Anneau
    (Refuser : tout)
    • Guerriers
      (Autoriser : Armes, Bière, Rations pour les Elfes, Porc salé)
      • Aragorn
        (Autoriser : Diplomatie)
      • Legolas
      • Gimli
    • Magiciens
      (Autoriser : Porc salé, Diplomatie, Bière)
      • Gandalf
    • Hobbits
      (Autoriser : Bière)
      • Frodo
        (Autoriser : Anneau)
      • Bilbo
      • Merry
        (Refuser : Bière)
      • Pippin
        (Autoriser : Diplomatie)
    • Visiteurs
      (Autoriser : Porc salé)
      • Gollum

Cette approche nous donne plus de possibilités pour faire des changements de permissions de grande ampleur, mais aussi des ajustements plus précis. Cela nous permet de dire que tous les hobbits peuvent accéder à la bière, avec une exception — Merry. Pour voir si Merry peut accéder à la bière, nous aurions trouvé son chemin dans l'arbre : Communauté->Hobbits->Merry et appliqué notre principe, en gardant une trace des permissions liées à la bière :

Nœud de l'ARO Information sur la permission Résultat
Communauté de l'Anneau Refuse tout Refuser l'accès à la bière.
Hobbits Autorise la bière Autoriser l'accès à la bière !
Merry Refuse la bière Refuser la bière