Les rôles et les restrictions dans Wikibase

[benbober]

Ce ticket permet de synthétiser en un seul l’ensemble des tickets qui ont trait aux rôles, aux restrictions et à leur implémentation dans le FNE. Il s’agit des tickets #40, #58, #59, #64, #97, #98, #51. Par ailleurs, les tickets #108 , #109, #110, #122, #123, #124, #125, #126, et #127 qui entraient plus dans des détails d’implémentations des thématiques évoquées ici sont désormais clos. En amont du rapport final qui devra donner un avis spécifique sur chacune de ces fonctionnalités, l’objet du présent ticket est de fournir des orientations de plus haut niveau sur ce qu’il conviendrait de faire pour répondre aux besoins spécifiques du POC sur cette question des rôles et des restrictions.

• Niveau d’implication dans la communauté (gouvernance, développements, etc. ?) afin de rendre Wikibase le plus conforme possible à nos attentes. Il s'agit de pointer vers les discussions, tickets en cours sur phabricator permettant de connaître l'état de l'art sur la question et les orientations à venir
• Développement d’une surcouche exploitant les API de wikibase (lesquelles ?) et implémentant les fonctionnalités absentes de l’interface native de wikibase.

L’avis portera plus particulièrement sur les 3 points suivants

• Certaines données (ex dates de vie) ne peuvent être visibles que par des utilisateurs logués, quels que soient les moyens d’accéder à ces données (interface, webservice, query service)
• La création et la modification d’entités ne peuvent se faire que par un utilisateur logué
• Il doit être possible de créer et administrer des groupes d’utilisateurs logués ayant des droits particuliers (ex tel groupe peut créer des propriétés ou fusionner des entités, tel autre non.) Les avis s’appuieront sur les discussions de la communauté (tickets, discussion sur les listes,…) permettant de connaître les orientations futures et vers lesquelles il faudra pointer. Le ticket est considéré clos lorsque le ticket #212 a été lui-même clos et que les éléments de réponse ont été amenés en commentaire.

[jum-s]

La création et la modification d’entités ne peuvent se faire que par un utilisateur logué

Un paramétrage des groupes utilisateurs permettrait de satisfaire cette spec : Les lignes suivantes désactivent l'édition des pages par tous, et créent un groupe appelé emailconfirmed avec les droits d'édition et de création:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['createpage'] = false;
# Only confirmed email addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
$wgGroupPermissions['emailconfirmed']['edit'] = true;
$wgGroupPermissions['emailconfirmed']['createpage'] = true;

source: https://www.mediawiki.org/wiki/Manual:User_rights

[jum-s]

Il doit être possible de créer et administrer des groupes d’utilisateurs logués ayant des droits particuliers

Est-ce que l'interface du fichier LocalSettings.php est suffisante pour cette spec, aucune interface graphique n'est disponible a ma connaissance pour gérer les droits administrateurs (à confirmer pendant l'exploration en tant que telle)

[gotnc]

Suite à notre discussion d'hier sur une granularité possible sur les habilitations et flux d'entités, et pour compléter ce qui est déjà listé au dessus, voilà d'autres exemples qui ne reflètent pas de cas d'usage (ils sont à préciser) mais qui pourraient se rapprocher de ce que l'on aura besoin de faire :

• une entité à statut "validé" ne peut être modifiée que par un groupe restreint d'utilisateurs (conditions sur la propriété statut de l'entité)
• une entité à statut "courant" peut être modifiée par un groupe élargi d'utilisateurs (conditions sur la propriété statut de l'entité)
• certains types d'entités ne sont modifiables que par un groupe d'utilisateur (conditions sur la propriété type d'entité)
• certaines propriétés spécifiques à une institution ne peuvent être éditées que par des utilisateurs enregistrés comme faisant partie de cette institution (modification de certaines propriétés d'une entité + groupe d'utilisateurs par institution)

[jum-s]

Les groupes d'utilisateurs sont :

• consultables via la page ListGroupRights

• créés uniquement via la configuration dans LocalSettings.php, notamment $wgGroupPermissions détaillé plus bas

• applicables/assignables aux utilisateurs

  • via l'interface graphique sur la page UserRights
  • via un script de maintenance createAndPromote ex : php createAndPromote.php --custom-groups=catalogueur username

Restrictions à la lecture

Visibilité des entités

Empêcher la consultation des entités est possible via la restriction des pages elles-mêmes :

• S'assurer d'abord que l'accès à l'édition des données aux utilisateurs anonymes est interdit

$wgGroupPermissions['*']['editpage'] = false;

• Interdire l'accès à la lecture des données aux utilisateurs anonymes

$wgGroupPermissions['*']['read'] = false;

• Avec les lignes ci-dessus, les utilisateurs peuvent toujours se créer un compte. Considérer alors la possibilité d'interdire la création de compte :

$wgGroupPermissions['*']['createaccount'] = false;

Visibilité des déclarations

La possibilité de restreindre l'accès seulement à certaines déclarations dans une entité n'est pas envisagée par la communauté Wikibase.

Un moyen de restreindre cet accès pourrait être de dupliquer l'entité dans plusieurs 'Namespaces' (ex: Item pour les éléments avec les déclarations sensibles et publicItem sans ces données), et d'attribuer des interdictions sur les Namespace via $wgNamespaceProtection

Restrictions à l'écriture

Edition d'une entité spécifique

La restriction de modification d'entité se fait via la protection de la page de l'entité

Cette fonctionnalité issue de Mediawiki est accessible

• dans l'interface graphique via l'action protect
• ou par la variable de configuration $wgRestrictionLevels

Édition d'un type d'entité

Les restrictions sur les types d'entités peuvent s'appliquer en protégeant toutes les pages d'un Namespace particulier avec la variable $wgNamespaceProtection

Édition de propriété uniquement par les utilisateurs d'une institution

Il existe la possibilité de créer deux groupes (nommé abes et bnf par exemple) et de protéger l'édition de la propriété en question dans l'interface graphique via l'action protect

Restriction des services

Par définition, la restriction d'accès à un autre service que Wikibase ne peut être réalisée sur Wikibase. Un utilitaire/wrapper autour du service pourrait être envisagé avec une authentification Oauth, cet utilitaire devra assurer la responsabilité de sauvegarde des tokens.

Cas d'usage : Groupe catalogueur

Défini dans l'issue #127

• Créer et modifier des éléments

  $wgGroupPermissions['catalogueur']['createpage'] = true;
  $wgGroupPermissions['catalogueur']['edit'] = true;

• Ne peut pas créer de propriété

  $wgGroupPermissions['catalogueur']['property-edit'] = false;

• Ne peut pas fusionner d'entité

Cela revient à interdire l'accès à la page Special:MergeItems La restriction des pages spéciales est possible via l'extension Lockdown

$wgSpecialPageLockdown['MergeItems'] = [ 'catalogueur' ];

[gotnc]

Merci pour vos retours et pistes.

Une petite remarque toutefois à propos de l'utilisation possible de l'extension Lockdown : nous avons regardé et la doc ici https://github.com/wikimedia/mediawiki-extensions-Lockdown nous parait indiquer que ce serait tordre un peu le modèle que d'essayer d'utiliser cette extension WB pour restreindre l'accès aux données, voir par exemple : "Mediawiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not support full featured, air-tight protection of private content. This extension can be used to apply read-restrictions to namespaces, limiting read access to specific groups. Note however that there may be several ways in which data thusly protected may be "leaked" to the public:

• it is possible to include protected pages as templates, making them readable. This is addressed by the $wgNonincludableNamespaces setting introduced in MW 1.10, revision 19934.
• it is possible to export pages without having read-access to them using Special:Export. This has been fixed in MW 1.10, revision 19935.
• Content of newly created pages, and changes to existing pages, are shown in the RSS/Atom feeds provided by Special:recentchanges, without checking read permission. This has been fixed in MW 1.10, revision 19944.
• Read-Permission only applies to page content. "Hidden" pages are still listed in categories, Special:Allpages, etc. Also, changes to "hidden" pages are still shown Special:Recentchanges, etc, including the edit summary.
• Excerpts of page content may be shown by Special:Search, regardless of read permission. There are probably more "holes" in the read protection system. So, denying read access should be seens as a "nothing to see here, move along", rather than a guarantee of secrecy."

De la même manière, dupliquer des millions d'entités sous différents namespaces ne semble pas une solution réellement adaptée au besoin décrit. Dans le rapport de fin de POC, sera-t-il possible de détailler plus à fond les limites des fonctionnalités évoquées et manques pour répondre au besoin, ainsi que les actions à entreprendre si l'on s'orientait tout de même vers cette approche ?

[jum-s]

Aucune solution préexistante ne semble être disponible pour couvrir les besoins décrits. La sécurisation des données sensibles n'est pas dans les objectifs de Wikibase et nous savions tous que le poc allait coincer sur ce sujet.

D'autres pages essaient de palier aux limites de Mediawiki, mais il n'en reste pas moins que le logiciel a été créé pour des données ouvertes. Certaines pages laissent perplexe quant à la satisfaction de vos besoins : "almost all hacks or patches promising to add [per-page access restrictions] will likely have flaws somewhere". Toutes restrictions d'accès est vu comme un contournement du logiciel.

Le POC (et précisément le rapport final) documentera les impossibilités à ce sujet et nous détaillerons les lectures sur la sécurité des données personnelles. Néanmoins nous souhaitons aussi proposer l'exploration de certaines pistes (et leurs limites), d'ou la duplication d'entités.

L'une des forces de wikibase est de pouvoir traiter des dizaines de millions d'entités, la duplication dans des namespaces, pour nous, bute sur d'autres contraintes que la masse d'entité. Par exemple, comment gérer le transfert d'un namespace à l'autre ou la référence inter-namespace. Il serait possible de créer des utilitaires qui assurent la mise à jour des données entre différents namespaces, mais les incertitudes restent grandes sur la maintenabilité de cette piste d'exploration.

Autre piste qui sera détaillée dans le rapport : un proxy qui viendrait filtrer les requêtes sur certaines pages, en dehors de Wikibase pour éviter les contournements internes découragés.

[gotnc]

Ok merci