Liste de contrôle d'accès (ACL)

DokuWiki - comme la plupart des wikis - est très ouvert par défaut. Chacun peut y créer, éditer et effacer des pages. Toutefois il est compréhensible parfois de limiter l'accès à certaines ou à toutes les pages. C'est alors que la liste de contrôle d'accès (ACL) joue son rôle. Cette page vous livre une vue d'ensemble du fonctionnement de l'ACL dans DokuWiki et sa configuration.

Les ACLs peuvent être activés à l'installation et une politique initiale minimale est créée à ce moment là. Tout peut être dorénavant configuré par interface graphique dans le gestionnaire de la liste des contrôles d'accès. Cependant, vous pouvez activer manuellement les ACLs dans DokuWiki. Pour cela, veuillez configurer le paramètre useacl dans le gestionnaire des paramètres de configuration. Puis renommez ou copiez simplement les fichiers d’exemple conf/acl.auth.php.dist et conf/users.auth.php.dist en respectivement conf/acl.auth.php et conf/users.auth.php. et la page de procédure de connexion devrait fonctionner.

Il y a quelques options supplémentaires de configuration qui permettent le contrôle d'autres aspects des ACLs mais beaucoup trouveront les configurations par défaut satisfaisantes.

• Paramètre de configuration useacl – active les ACLs. Un bouton S'identifier apparaît.
• Paramètre de configuration superuser – active le super-utilisateur avec tous les droits ACLs.
• Paramètre de configuration disableactions – interdit l’enregistrement des utilisateurs.
• Paramètre de configuration defaultgroup – Groupe par défaut dans lequel les nouveaux utilisateurs. sont ajoutés.
• User Manager – gestionnaire des utilisateurs.
• Authentication Backends – identifie les utilisateurs depuis différents connecteurs d'authentification.
• FAQ: Comment désactiver l'inscription libre des utilisateurs ?

Sécurité: La fonctionnalité des ACLs est présente dans DokuWiki depuis longtemps et s'avère plutôt stable. Pour la sécurité de vos données, ne mettez jamais des informations sensibles dans votre wiki qui sont, malgré la robustesse des ACLs, potentiellement accessibles par internet.

Des restrictions d'accès peuvent être liées aux pages et aux espaces de noms. Il y a sept permissions : aucune (none), lire (read), modifier (edit), créer (create), téléverser sur le serveur (upload), effacer (delete) et administrer (admin). Les permissions de niveau plus élevé contiennent celles des niveaux inférieurs, aucune étant le niveau le plus bas et administrer le plus haut. Mais dans l'usage du wiki pour les utilisateurs lire est le plus bas et effacer est le plus haut niveau. Notez que les permissions de créer, télécharger et effacer ne sont assignées qu’aux espaces de noms.

Les règles définies aux espaces de noms s'appliquent aussi bien pour les médias et pour les pages des espaces de noms.

Quand DokuWiki contrôle les droits qu’il doit attribuer à un utilisateur, il utilise toutes les règles contenant le nom d’utilisateur ou de groupe.

La règle qui donne la permission la plus élevée est utilisée selon ce processus :

• Les règles qui correspondent aux permissions en proximité proche du namespace:page sont en priorité examinées (correspondance explicite spécifique à une page). Ensuite tous les espaces de noms supérieurs sont contrôlés jusqu'à ce qu'une règle soit trouvée.
• Quand plusieurs règles correspondent au même niveau, la règle donnant le plus de droits est retenue.

Les utilisateurs sont assignés dans des groupes via le gestionnaire d'utilisateurs ou depuis différents connecteurs d'authentification. Toutefois, deux groupes sont, d'une certaine manière, spéciaux :

• @ALL. Tout le monde, même les utilisateurs non connectés, est membre du groupe ALL. Vous pouvez utiliser ce groupe pour limiter l'accès à tous les utilisateurs (comme configuration par défaut) et autoriser certaines permissions pour quelques utilisateurs choisis.

• @user. Tous les utilisateurs qui se sont enregistrés sont automatiquement membres du groupe « user » par défaut. Utilisez-le pour attribuer des privilèges aux utilisateurs connectés. Le nom de ce groupe est configuré avec l'option defaultgroup. Contrairement au groupe virtuel « ALL » , le groupe « user » est un vrai groupe auquel tous les utilisateurs sont ajoutés automatiquement en utilisant l’authentification en mode texte. Si vous utilisez un autre mode d’authentification vous aurez besoin d'utiliser les groupes fournis par ce mode.

Les groupes sont représentés en interne et dans le gestionnaire des contrôles d'accès (ACLs) par un préfixe, le caractère: @ suivi du nom du groupe. Par exemple: @user

Pour facilement ajouter ou changer des permissions dans la liste de contrôles d'accès, rendez-vous via le menu Administrer dans la Gestion de la liste des contrôles d'accès (ACLs) dont vous trouverez le détail ici.

Pour ajouter une nouvelle règle, il y a essentiellement trois étapes:

1. sélectionner l'espace de noms ou la page, en navigant en haut à gauche dans l'arborescence de votre wiki.
2. choisisser à qui doit s'appliquer la règle :
   • en sélectionnant un groupe ou un utilisateur connu dans le menu déroulant ou,
   • en sélectionnant “User:” ou “Group:” et en entrant le nom d'un groupe ou d'un utilisateur dans le champ.
3. paramétrer la permission appropriée.

Les règles existantes peuvent être modifiées ou supprimées en bas dans le tableau du gestionnaire de la liste des contrôles d'accès (ACL)s.

Dans cette partie, nous allons voir comment les règles d'accès fonctionnent, en utilisant un exemple fictif tel qu'il peut apparaître dans le gestionnaire de la liste des contrôles d'accès (ACL).

Et les explications ligne par ligne :

1. Fixe la permission pour l’espace de nom principal. Permet à tout le monde d'éditer et de créer des pages. Cependant, on ne permet pas le téléversement.
2. l’utilisateur bigboss a tous les droits.
3. Restriction pour l’espace de nom devel. Personne n'est autorisé à y faire quoi que ce soit.
4. En fait pas vraiment personne - tous les droits sont donnés aux membres du groupe devel.
5. Et naturellement on donne les autorisations à l’utilisateur bigboss aussi, qui est le seul à pouvoir supprimer des fichiers téléversés.
6. L'équipe marketing a l'autorisation de lire le contenu de l’espace de nom devel, mais pas de le modifier.
7. L'équipe devel ne veut pas que leur boss voit la page funstuff. Rappelez-vous que l'exacte correspondance explicite en droits d'une page surpasse les permissions supérieures d'un namespace.
8. Et pour finir, l'équipe marketing a l'autorisation de modification de la page devel:marketing.
9. Les permissions pour l’espace de nom marketing sont fixées. Tous les membres du groupe marketing sont autorisés à télécharger vers le serveur dans cet espace - les autres utilisateurs sont assignés par la ligne 1, ils sont limités à la création et à l’édition. L’utilisateur bigboss hérite de ses droits de la ligne 2 et peut aussi télécharger.
10. La dernière ligne concerne la page start qui est autorisée en lecture seule pour tout le monde. Seuls, les super-utilisateurs seront toujours capables de modifier cette page.

Essayons avec un deuxième exemple pour bien comprendre la correspondance explicite spécifique à une page.

Cette fois, nous allons examiner quelles sont les règles qui s'appliquent à différents utilisateurs qui veulent accéder à la page : private:bobspage.

1. abby, une utilisatrice normale, sans droits particuliers (regular user)
   • trois règles correspondent, #1, #2, #4
   • la règle #4 est la plus proche, elle correspond au niveau du namespace, donc, elle prend le dessus sur les trois règles précédentes.
   • le niveau d'autorisation de abby est Aucune (None)
2. bob, un utilisateur normal (regular user)
   • quatre règles correspondent, #1, #2, #4, #6
   • la règle #6 l'emporte comme correspondance explicite spécifique
   • le niveau d'autorisation de bob's est Effacer (Delete)
3. bob oublie de s'identifier et essaie d'accèder à sa page
   • deux règles correspondent, #1 & #4
   • la règle #4 est la plus proche, elle l'emporte
   • le niveau d'autorisation de bob quand il est non identifié est Aucune (None)
4. charlie, un membre du staff
   • cinq règles correspondent, #1– #5
   • deux règles correspondent au niveau du namespace, la #5 donne à charlie la plus haute permission et donc elle l'emporte
   • le niveau d'autorisation de charlie est Effacer (Delete)

Note: la règle #5 semble dire la même chose que la règle #3. Pourtant, sans elle, les membres du staff se verraient interdire d'accès au private namespace à cause de la règle #4.

Les restrictions d'accès sont archivées dans le fichier conf/acl.auth.php, qui doit être accessible en écriture par le serveur web si vous voulez utiliser le gestionnaire de la liste des contrôles d'accès (ACLs). Il n'est pas recommandé d'éditer ce fichier manuellement. Il est préférable de passer par le menu d'administration.

Les lignes vides ou commentées sont ignorées. Chaque ligne contient 3 zones séparées par des espaces :

• La ressource à limiter. Ceci peut être un nom de page ou un espace de nom. Les espaces de noms sont marqués par un astérisque supplémentaire (voir ses exemples ci-dessous)
• Un groupe ou un nom d'utilisateur. Les noms de groupe commencent par le caractère @.
• Un niveau de permission (voir ci-dessous)

Il y a 7 niveaux de permissions représentés par un nombre entier. Les plus hauts niveaux incluent ceux qui sont en dessous. Ainsi si vous avez l'autorisation de modifier, vous pouvez également lire. Cependant, l'autorisation admin de 255 ne peut pas être utilisée dans le fichier conf/acl.auth.php. C'est géré en interne selon l'option superuser.

Voici un exemple :

*                     @ALL        4
*                     bigboss    16
devel:*               @ALL        0
devel:*               @devel      8
devel:*               bigboss    16
devel:*               @marketing  1
devel:funstuff        bigboss     0
devel:marketing       @marketing  2
marketing:*           @marketing  8
start                 @ALL        1

L'ordre dans ce fichier n'a aucune importance car le fichier est parcouru et analysé dans sa globalité, de manière complète à la recherche d'une correspondance permission utilisateur/page courante. Quand une correspondance est trouvée, la recherche s'arrête simplement. Si aucune correspondance n'est trouvée, les permissions du groupe sur la page sont analysés et en l'absence d'un résultat positif, la vérification continue dans le prochain espace de noms au niveau supérieur.

Note: Pour configurer des utilisateurs ou des groupes comportant des caractères spéciaux (comme des espaces blancs), vous devez échapper les caractères dans les chaines d'URL. Ceci ne concerne que les caractères spéciaux dans le bas de la plage des 128 octets. Le fichier ACLs utilise l'encodage UTF-8 de sorte que toute les caractères multi-octets peuvent être écrits.

Note: Quand $conf['authtype'] = 'ad'; est utilisé et que les noms des groupes comportent des espaces blancs, le fichier acl.auth.php a besoin d'une conversion des espaces avec un “%5f” au lieu de “%20”. Ceci parce que les espaces dans les noms de groupes sont convertis en premier avec le tiret bas “_” soit “%5f”.

Note: La permission d'effacement affecte les fichiers de médias seulement. Les pages peuvent être effacées (et restaurées) par chacun. Quelqu'un qui n'a que des permissions de téléchargement mais aucune permission d'effacement ne peut écraser les fichiers de médias existants.

Il est possible d'utiliser un motif de remplacement dans les ACLs. Cela s'avère très utile pour les wikis avec beaucoup d'utilisateurs enregistrés quand vous voulez donner à chaque utilisateur ou groupe un espace de noms personnel. Au lieu de donner des droits pour chacun d'entre eux, vous pouvez utiliser la variable %USER% qui sera remplacée à la volée au moment de l'authentification par le nom d'utilisateur (username) et la variable %GROUP% par celle du ou des groupes auxquels il appartient.

Dans l'exemple suivant, un utilisateur authentifié obtient un privilège complet sur les permissions (upload/delete) pour l'espace de noms utilisateur user:<username>:* et révoque tous les accès à partir d'autres espaces de noms situés dans user: * .

#
# Accorde un accès complet aux utilisateurs dans :user
user:%USER%:*          %USER%  AUTH_DELETE
#
# Autorise la lecture dans son propre espace de noms et à naviguer via l'index
user:                  %USER%  AUTH_READ
#
# Autorise la lecture seulement dans la page start située dans  :user
user:start             %USER%  AUTH_READ
#
# Désactive tous les accès à l'espace personnel dans l'espace de noms :user 
#au groupe @user lorsqu'ils ne sont pas authentifiés par la variable %USER%, 
# incluant la vue de l'index des pages et espaces de noms.
user:*                 @user   AUTH_NONE
#
# Autorise les membres de 'group' à modifier les pages dans l'espace de noms 
# 'group'. Soyez vigilant, si vous avez un espace de noms utilisateurs, 
# tous les membres du groupe par défaut y auront accès.
%GROUP%:*               %GROUP% AUTH_EDIT

Note: Avertissement pour la version 2009-12-25c “Lemming”. Si vous ajoutez, mettez à jour ou supprimer les entrées des ACLs depuis l'interface d'administration, DokuWiki remplacera %USER% dans le second champ des ACLs par %25USER%25 (c'est unbug FS#1955). Pour l'éviter, changer manuellement les permissions (en éditant: conf/acl.auth.php) ou corrigez les manuellement après chaque changement dans l'interface d'administration car %25USER%25 ne fonctionne pas comme attendu. Seul %USER% devrait être utilisé dans conf/acl.auth.php. Ce bug a été corrigé dans les plus récentes versions.

Note: Le motif de remplacement (wildcard) a changé en décembre 2008 de @ à % – si vous faîtes une mise à niveau à partir d'une ancienne version, vous devez modifier en conséquence vos paramètres dans les ACLs.

— Philippe LAPEYRIE 2006-05-19 00:12
— Digitalin 2016-02-20 15:23 Mise à jour