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

Les listes de contrôle d'accès (ACL) permettent aux administrateurs du wiki de donner à certains utilisateurs ou groupes d'utilisateurs le droit d'effectuer certaines actions (lire, écrire, supprimer) sur des pages déterminées. Ces listes permettent :

Pour utiliser les listes de contrôle d'accès, vous aurez besoin soit d'avoir accès au paramétrage du wiki (pour définir les droits d'accès communs au site), soit d'avoir les droits d'administration (admin) sur les pages dont vous souhaitez créer ou modifier les listes de contrôle d'accès des pages.

1. Sommaire

Sommaire

  1. Sommaire
  2. Bases
  3. Paramétrage
  4. Syntaxe
  5. Définition des droits
  6. Logique de fonctionnement pour une page isolée
  7. Hériter des valeurs par défaut
  8. Traitement hiérarchique des listes de contrôle d'accès
  9. Les groupes
  10. Exemples d'utilisation
    1. Wiki d'une communauté publique sur internet
    2. Un système simple de gestion d'informations (CMS)
    3. Wiki sur un réseau interne (intranet)
    4. Site public d'une société
    5. Commentaires sur une page en lecture seule
  11. Références

2. Bases

Les droits d'accès qu'il est possible de contrôler sont :

L'utilisation de listes de contrôle d'accès dans MoinMoin est très simple : il suffit d'ajouter une ligne de contrôle en haut de la page que vous désirez contrôler. Cette ligne de contrôle ressemble à ceci : 

#acl UnUtilisateur:read,write All:read

Cela permettra à UnUtilisateur de lire et d'écrire sur cette page et à tous les autres de lire cette page sans pouvoir y écrire (à moins que vous n'ayez mis en place des paramètres spécifiques dans la configuration du site).

/!\ Les pièces-jointes, lorsque l'on y accède via le moteur du wiki, sont également protégées par la liste de contrôle d'accès de la page à laquelle elle sont rattachées.

3. Paramétrage

Les options suivantes sont utilisées pour paramétrer les listes de contrôle d'accès :

Option

Valeur par défaut

Description

acl_rights_before

u""

Liste de contrôle d'accès appliquée avant la liste de la page ou la liste par défaut.

acl_rights_after

u""

Liste de contrôle d'accès appliquée après la liste de la page ou la liste par défaut.

acl_rights_default

u"Trusted:read,write,delete,revert \
Known:read,write,delete,revert \
All:read,write"

Utilisé uniquement si aucune liste de contrôle d'accès n'est donnée dans la page accédée.

acl_rights_valid

["read",  "write",  "delete",  "revert",  "admin"]

La liste des droits valides (reconnus) — et l'endroit où ajouter des extensions si nécessaire.

acl_hierarchic

False

Active le traitement hiérarchique des listes de contrôle d'accès, voir la section Traitement hiérarchique des listes de contrôle d'accès.

Ce tableau vous indique le rôle de chaque paramètre, mais pas ce qu'il signifie :

Il peut être utile de penser à ces paramètres comme les listes de contrôle d'accès appliquées avant, pendant et après le traitement des listes de contrôle d'accès de la page.

(!) La notation u"" utilisée dans le paramétrages des listes de contrôle d'accès indique l'utilisation de chaînes de caracères Unicode. Leur utilisation est impérative — consultez l'AideDeParamétrage pour plus d'informations.

/!\ Si vous utilisez le paramétrage par défaut (anglais) de définition des noms de goupes, et que vous souhaitez utiliser des noms de groupes n'étant pas en CasseAlternée (p. ex. : « PROJECTGroup »), vous devrez modifier la définition par défaut des groupes page_group_regex en lui donnant pour valeur : u'[a-z0-9,A-Z]Group$'

{i} Attention, la version française de cette page suppose que vous ayez configuré les groupes comme indiqué à la fin de la section Groupes.

4. Syntaxe

Chaque ligne doit respecter la syntaxe suivante : 

#acl [+-]Nom[,Groupe,...]:[droit[,droit,...]] [[+-]AutreNom:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]

Où :

/!\ N'ajoutez pas de blancs entre le nom et les droits associés : « All: write,read » ne sera pas une liste de contrôle d'accès correcte.

5. Définition des droits

Voici la liste des droits que vous pouvez utiliser dans les règles composant votre liste de contrôle d'accès. Attention cependant, l'utilisateur doit être membre (implicite) du groupe Known pour avoir le droit de renommer ou de supprimer une page, même si le droit de suppression (delete) lui a été accordé.

read
Les utilisateurs indiqués pourront lire le texte de cette page.
write
Les utilisateurs indiqués pourront écrire (éditer) le texte de cette page.
delete
Les utilisateurs indiqués pourront supprimer cette page et ses pièces jointes.
revert
Les utilisateurs indiqués pourront restaurer une ancienne version de cette page.
admin
Les utilisateurs indiqués bénéficieront des droits d'administration sur cette page. Ce qui veut dire qu'ils pourront modifier la liste de contrôle d'accès de cette page, y compris en donnant ou en supprimant les droits d'administration à d'autres.

/!\ Il n'existe pas de droit correspondant au renommage d'une page. Pour renommer une page, l'utilisateur doit disposer des droits de lecture (read), d'écriture (write) et de suppression (delete).

6. Logique de fonctionnement pour une page isolée

Lorsqu'un utilisateur essaie d'accéder à une ressource protégée par une liste de contrôle d'accès, celle-ci sera appliquée selon l'ordre où elle a été écrite. La première règle pouvant s'appliquer à l'utilisateur servira a déterminer si l'utilisateur a accès ou non à la ressource. Le traitement de la liste de contrôle d'accès s'arrêtera dès qu'une règle correspondant à l'utilisateur aura été trouvée.

(!) Du fait du choix d'utiliser la première correspondance, il est préférable de trier vos listes de contrôle d'accès en indiquant en premier les noms d'utilisateurs individuels, puis les groupes spécialisés, suivis des groupes plus généraux, puis Known et enfin All.

Par exemple, la liste de contrôle d'accès suivante indique que UnUtilisateur à le droit de lire et d'écrire la ressource protégée. Tous les membres du groupe GroupeExemple (sauf UnUtilisateur s'il en fait partie) auront également le droit d'administrer cette page. Enfin, tous les autres utilisateurs auront le droit de la lire. 

#acl UnUtilisateur:read,write GroupeExemple:read,write,admin All:read

Pour rendre ce système plus souple, il existe également deux modificateurs : les préfixes « + » et « - ». Lorsque ces modificateurs sont utilisés, le traitement de la liste de contrôle d'accès ne s'arrêtera que lorsque le droit demandé pour un utilisateur correspond à la fois à l'utilisateur et au droit indiqué dans la règle donnée. Le traitement continuera si l'on recherche un autre droit (ou un autre utilisateur). S'il y a correspondance, dans le cas de « + », le droit sera accordé, dans celui de « - », il sera refusé.

Par exemple, en supposant que UnUtilisateur soit membre du groupe GroupeExemple, la liste de contrôle d'accès ci-dessus pourrait être reformulée comme ceci : 

#acl -UnUtilisateur:admin GroupeExemple:read,write,admin All:read

Cet exemple n'est particulier que pour UnUtilisateur, car lors de la vérification du droit d'administration pour UnUtilisateur, le droit sera refusé et le traitement de la liste s'arrêtera. Dans tous les autres cas, le traitement continuera.

Ou même : 

#acl +All:read -UnUtilisateur:admin GroupeExemple:read,write,admin

+All:read indique que lorsqu'un utilisateur quel qu'il soit demande le droit de lecture, il lui est accordé et le traitement s'arrête. Dans tous les autres cas, le traitement de la liste se poursuivra. Lors de la vérification du droit d'administration pour UnUtilisateur, ce droit sera refusé et le traitement s'arrêtera. Dans tous les autres cas, le traitement de la liste se poursuivra. Enfin, si un membre de GroupeExemple demande un droit, il sera accordé s'il est indiqué ici et refusé autrement. Aucun autre utilisateur n'aura d'autre droit, à moins que ceux-ci soient donnés par la configuration.

Remarquez que les deuxième et troisième exemples ne sont pas très indiqués comme liste de contrôle d'accès d'une page. Ils peuvent par contre être très utiles dans les paramètres de configuration d'un site.

7. Hériter des valeurs par défaut

Il est parfois utile de donner des droits à quelqu'un sans trop modifier les droits par défaut. Par exemple, supposons que votre configuration contienne les paramètres suivants : 

acl_rights_default = u"GroupeAuteur:read,write,delete,revert All:read"
acl_rights_before  = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"

Maintenant, vous souhaitez accorder à UnUtilisateur le droit d'écrire (write) sur une page, mais vous souhaitez conserver les droits par défaut des groupes ALL et GroupeAuteur. Vous pourrez facilement le faire en ajoutant une règle Default : 

#acl UnUtilisateur:read,write Default

Cette règle va ajouter le contenu du paramètre acl_rights_default à l'endroit exact où est placé le mot Default. En d'autres termes, la liste ci-dessus associée au paramétrage indiqué sera équivalente à la liste suivante : 

#acl UnUtilisateur:read,write GroupeAuteur:read,write,delete,revert All:read

Examinez maintenant le premier exemple de cette section : 

acl_rights_before  = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"

Les listes de contrôle d'accès sont traitées dans l'ordre suivant : liste du paramètre « avant » (before), liste de la page ou liste par défaut (default) puis, pour terminer, liste du paramètre « après » (after). Les listes de contrôle d'accès sont traitées de gauche à droite.

Donc, nous commençons à gauche de la liste contenue dans le paramètre before avec GroupeAdmin:... — cette règle s'applique si vous êtes un membre du groupe admin. S'il y a correspondance, les droits indiqués vous sont accordés (arwdr) et le traitement des listes de contrôle d'accès s'arrête.

S'il ne correspond pas, le traitement des listes continue. La règle suivante est : +GroupAuteur:admin — cette règle s'applique si vous êtes un membre du groupe auteur.

S'il y a correspondance, le droit (a) vous est accordé et — le cas est différent car la règle utilise un modificateur — le traitement des listes de contrôle d'accès continue ! Donc, s'il y a une autre correspondance pour ce groupe, votre nom d'utilisateur ou Known ou All vous bénéficierez également de ces droits.

S'il n'y a pas correspondance, le traitement continue.

Le traitement se poursuit donc avec la liste de contrôle d'accès de la page (s'il y en a une) ou la liste de contrôle d'accès par défaut (sinon), puis enfin par la liste de contrôle d'accès contenue dans le paramètre after.

Bien que ces listes soient équivalentes, hériter de la liste par défaut présente l'intérêt d'intégrer automatiquement toutes les modifications apportées à la liste de contrôle d'accès par défaut.

8. Traitement hiérarchique des listes de contrôle d'accès

{i} Nouvelle fonction de la version 1.6.

Si vous avez activé l'option acl_hierachic (voir ci-dessus), les pages seront gérées en tenant compte de leurs relations hiérarchiques. Les droits appliqués aux pages situées au-dessus pourront influencer les droits des utilisateurs.

Le principe est simple, si les droits ne peuvent être déterminés avec la page en cours, la liste de contrôle d'accès de la page du niveau supérieur est vérifiée. Si celle-ci ne suffit pas pour déterminer l'accès, on remonte encore d'un niveau. Et ainsi de suite.

L'algorithme de correspondance appliqué à chaque page, tel qu'il est expliqué ci-dessus, reste le même. Cependant, la ligne #acl de la page est complétée par les listes de contrôle d'accès de chacune des pages de la hiérarchie, jusqu'à la racine. Pour une page appelée A/B/C/D, voici ce que donneront les deux modes de fonctionnement :

acl_hierarchic

Séquence de traitement

false

acl_rights_before, A/B/C/D, [acl_rights_default], acl_rights_after

true

acl_rights_before, A/B/C/D, A/B/C, A/B, A, [acl_rights_default], acl_rights_after

Les règles acl_rights_before, acl_rights_default et acl_rights_after ne sont pas appliquées pour chaque page de la hiérarchie, mais une fois pour toute au cours du traitement de la page A/B/C/D. Les droits par défaut fonctionnent de la même façon qu'auparavant, mais ne seront appliqués que si aucune des pages de la hiérarchie ne contient de liste de contrôle d'accès. Il est donc parfaitement exact de dire que la ligne #acl de la page est remplacée par la somme de toutes les lignes #acl de la page et de ses parents.

9. Les groupes

Les groupes d'utilisateurs facilitent la définition des droits pour de plus grand nombres d'utilisateurs.

Seul les amis de UnUtilisateur peuvent lire et modifier cette page : 

#acl UnUtilisateur:read,write UnUtilisateur/GroupeDesAmis:read,write

UnUtilisateur/GroupeDesAmis est une page contenant une liste de premier niveau dont chacune des entrées indique un nom d'utilisateur appartenant à ce groupe : 

#acl UnUtilisateur:read,write,admin,delete,revert
 * JeanDupont
 * PierreDurand
 * PaulMartin

Le groupe GroupeAdmin peut être défini par une page de même nom protégée par une liste de contrôle d'accès : 

#acl GroupeAdmin:admin,read,write All:read
 * UnUtilisateur
 * UnAutreUtilisateur
   * Ce texte est actuellement ignoré.
Tout autre texte non situé dans la liste de premier niveau sera ignoré.

/!\ Une liste de premier niveau est une liste avec une seule espace avant l'astérisque (et une seule espace après). L'exemple suivant ne marche pas : 

  * un utilisateur
-- l'astérisque est précédée de 2 espaces, donc ça ne marche pas.

Vous pouvez définir quels noms de pages sont considérées comme des pages de définition de groupes (par exemple pour des wikis nom-anglophones). 

page_group_regex =  u'[a-z]Group$' # valeur par défaut adaptée à un wiki anglophone

/!\ Si les modifications que vous avez apporté à une page de groupe ne sont pas pris en compte, supprimez tous les fichiers contenus dans le répertoire chemin_vers_votre_wiki/data/cache/wikidicts/, afin que MoinMoin reconstruise son cache.

10. Exemples d'utilisation

10.1. Wiki d'une communauté publique sur internet

Pour ce type d'utilisation, il est important de n'utiliser les listes de contrôle d'accès que là où c'est réellement nécessaire. Les wikis dépendent de la liberté d'accès à l'information et de la liberté d'édition. Ils se basent sur une sécurité douce pour nettoyer les entrées malveillantes. Donc, en général, les listes de contrôle d'accès ne sont pas nécessaires ; si vous en abusez, vous risquez de détruire ce qui fait la force des wikis.

C'est pourquoi soit les listes de contrôle d'accès ne devraient pas être utilisées du tout (ce qui est le paramétrage par défaut), soit, si elle sont utilisées, des paramètres tels que les paramètres ci-dessous devraient être utilisés dans le fichier wikiconfig.py : 

acl_rights_before = u'NomÉditeur:read,write,admin,delete,revert +GroupeAdmin:admin PersonneMalveillante:'

La valeur par défaut du paramètre acl_rights_default devrait vous convenir : 

acl_rights_default = u'Known:read,write,delete,revert All:read,write'

Il est recommandé d'avoir un petit groupe d'administrateurs de confiance dans le GroupeAdmin (ils devront bien connaître le fonctionnement d'un wiki, sinon, ils risquent de détruire sans le vouloir l'ouverture qui est la richesse d'un wiki).

Si vous utilisez un GroupeAdmin, créez une page appelée GroupeAdmin et utilisez-là pour indiquer la liste des personnes recevant les droits d'administration.

Indiquer PersonneMalveillante comme ci-dessus revient à empêcher cet utilisateur d'utiliser le wiki — il ne peut plus rien lire ni éditer avec son compte. Cela n'a de sens que comme mesure temporaire, autrement il vaut mieux carrément supprimer le compte. Naturellement, cette PersonneMalveillante peut aussi travailler anonymement, donc ce n'est pas une réelle protection (c'est ici que la sécurité douce entre en jeu).

10.2. Un système simple de gestion d'informations (CMS)

Si vous souhaitez utiliser le wiki pour créer simplement des pages web, mais que vous ne souhaitez pas que le public puisse le modifier (autrement dit, que les modifications soient limitées à un petit groupe de webmestres), vous pouvez utiliser une configuration comme celle-ci : 

acl_rights_default = u'All:read' 
acl_rights_before  = u'WebMestre,AutreWebMestre:read,write,admin,delete,revert'

Donc, tout le monde peut lire, mais seuls les webmestres peuvent faire quoi que ce soit d'autre. Tant que ceux-ci sont encore en train de travailler sur une nouvelle page, il peuvent indiquer sur celle-ci : 

#acl All:

Ce qui implique que personne d'autre ne sera capable de consulter une page avant qu'elle ne soit prête. Lorsque la page sera terminée, n'oubliez pas d'enlever cette ligne, afin que acl_rights_default soit à nouveau utilisé.

Quelques pages peuvent aussi être utilisée pour permettre des commentaires du public (par exemple, une page VotreAvis). Vous devrez donc accorder plus de droits sur ces pages : 

#acl All:read,write

10.3. Wiki sur un réseau interne (intranet)

Si vous souhaitez utiliser un wiki sur votre réseau interne d'entreprise et que vous avez suffisamment confiance en vos utilisateurs pour leur donner accès aux droits d'administration (vous pensez qu'ils ne réaliseront pas d'actions hostiles comme bloquer l'accès à certains utilisateurs ou détourner certaines pages), vous pouvez utiliser quelque-chose comme ceci : 

acl_rights_default = u'Known:admin,read,write,delete,revert All:read,write'
acl_rights_before  = u'AdminWiki,GrandChef:read,write,admin,delete,revert'

Ce qui veut dire que tout le monde peut lire, écrire et modifier les droits et que AdminWiki et GrandChef sont assurés de toujours avoir tous les droits. Les utilisateurs identifiés (Known) obtiennent les droits d'administration via le paramètre par défaut (acl_rights_default) — autrement dit, ils on les droits d'administration tant que la page ne contient pas de liste de contrôle d'accès.

Conséquences :

10.4. Site public d'une société

Si vous souhaitez utiliser un wiki comme site internet d'une société et que vous ne souhaitez pas que n'importe-qui puisse modifier le contenu du site, vous pourrez faire quelque-chose comme ceci : 

acl_rights_default = u"GroupeAuteur:admin,read,write,delete,revert All:read"
acl_rights_before  = u"GroupeAdmin:admin,read,write,delete,revert +GroupeAuteur:admin"

Ce qui veut dire que :

10.5. Commentaires sur une page en lecture seule

Il est facile d'ajouter une section commentaires à une page en lecture seule en utilisant une sous-page ouverte en écriture et en permettant aux utilisateurs d'y écrire. Par exemple, on peut définir UnePage comme ceci : 

#acl UnUtilisateur:read,write All:read
'''Quelques informations en lecture seule'''

...

'''Commentaires utilisateurs'''
<<Include(UnePage/Commentaires)>>

Et UnePage/Commentaires ainsi : 

#acl All:read,write
Ajoutez ici vos commentaires relatifs à la page UnePage.

11. Références

Site hébergé sur un Cloud Public IKOULA Ikoula