Reflexion sur la gestion des droits

[joelclems]

La gestion de l'accès aux données est quelque chose qui reste à implémenter pour ce module

Un décorateur d'accès au routes permet de fermer ces route si aucun droit n'est defini pour le module Mais il reste à gérer un filtrage CRUVED des données , en prenant en compte les permissions et l'appartenance des données.

Appartenance des données

L'appartenance d'une données est liée à la personne qui saisie, aux observateur ou au jeu de donnée En gras les champs manquants, l'organisme peut être déduis de ces champs (ou relations)

• groupe de sites (GS)
  • id_digitizer
• sites (S)
  • id_digitizer
  • id_inventor
• visites (V)
  • id_dataset
  • observers
• observations (O)
  • id_digitizer

Permissions

L'accès aux données est défini par un CRUVED liée au module ou au object de ce module (au sens des permission) Pour un administrateur on peut définir un cruved à 3 partout pour le module seuelement

Nous donnons un exemple de configuration d'un utilisateur dont on cherche à restreindre les droits, selon les actions et les objets concernés

Lecture

Un exemple ou on définirait un droit R de

• 3 (toutes les données) pour les groupe de site
• 2 (données de mon organisme) pour les sites
• 2 (données de mon organisme) pour les visite
• 1 (données de mon organisme) pour les observations

schématisé par

• GS: 3,
• S: 2,
• V: 1,
• O: 1

Update, Delete

la mise à jour des données et la suppression sont en général plus restrictive, on ne va permettre de n'agir que sur ces propres données

• GS: 1,
• S: 1,
• V: 1,
• O: 1

Create

Ici donner un droit 2 ou 3 en Create peut prendre un sens.

• un droit 2 en création sur les visite permet de créer une visite sur un site appartenant à son organisme
• un droit 3 permet de créer une visite sur n'importe quel site

Par exemple la configuration:

• GS: 0,
• S: 0,
• V: 3,
• O: 1

dit que l'utilisateur concerné:

• ne peut pas créer de groupe de site ou de site, cette tâche est laissé aux administrateur qui vont importer des données en base directement
• peut créer une visite sur n'importe quel site
• peut créer des observations seulement sur les visites qu'il a crée

[DonovanMaillard]

Merci Joel pour ces réflexions et cette première proposition.

Nous allons rejoindre/relancer les réflexions sur ces questions avec la Société Herpétologique de France, qui souhaite implémenter le cruved "classique" au niveau du module monitoring, et qui a la volonté de financer un premier lot de développements sur ce point (notamment pour limiter les droits de lecture). Je ne sais pas s'il y aura un besoin et les moyens d'aller aussi loin que tu le proposes en ayant la main sur toutes les actions, à tous les niveaux, mais en effet il faudra réfléchir à une base qui puisse être étendue pour arriver au fonctionnement que tu proposes.

L'approche que tu proposes va au délà du projet actuel de la SHF, mais il peut être intéressant que ces premiers développements posent une première brique à étendre ensuite. Globalement, la SHF pourrait commencer par implémenter le CRUVED de manière globale sur toutes les données du module, sans le décliner par objet : Si je peux lire les observations de mon organisme, alors je peux lire toutes les visites, les sites et groupes de sites qui correspondent de manière récursive. Si je peux mettre à jour les données de mon organisme, idem, je peux mettre à jour toutes les données d'observations, de visites, de sites et groupes de sites : sinon ça veut dire que j'ai un update à 1, et je ne peux alors modifier que les données (à tous les niveaux) qui m'appartiennent, càd dont je suis digitiser ou observateur ou descripteur du site etc.

Un besoin de la SHF qui ne trouve en revanche pas encore de réponse ici, ni dans le cruved de geonature de manière générale, est une restriction géographique : "je peux accéder à toutes les données en Bretagne, mais uniquement aux miennes hors de ce territoire". A voir si on peut réfléchir à cette notion de portée, et voir comment la croiser avec les autres niveaux au niveau de l'administration... Dans tous les cas, je reste preneur d'échanges sur le sujet pour avancer ensemble sur ce sujet.

[bouttier]

Restriction géographique

Dans le cadre du floutage développé par @jpm-cbna, plusieurs types de filtres ont été ajoutés, notamment filtre taxonomique et filtre géographique. On devrait donc être en mesure de répondre à ce besoin en définissant 2 permissions :

• scope=3, filtre géographique Bretagne
• scope=1, sans filtre géographique Reste à finaliser et merger le floutage.

[camillemonchicourt]

Actuellement, concernant les permissions dans Monitoring :

• On définit uniquement l'accès ou non au module au niveau des permissions globales sur le module (donc limité à l'action R). Depuis la suppression de l’héritage dans GeoNature 2.13.0, ces permissions du module ne se répercutent plus sur les sous-modules
• L'accès ou non et les actions possibles dans les sous-modules est définie au niveau de chaque sous-module
• Il peut être défini globalement au niveau du sous-module donc sur tous ses objets (groupes de site, sites, visites et observations), ou plus finement au niveau de chaque objet du sous-module (si défini au niveau de le configuration du sous-module comme sur https://github.com/PnX-SI/protocoles_suivi/blob/c0c1700523f24e1ce98c013149cbb44c0de09542/RHOMEOOdonate/config.json#L14-L19)

Il manque donc principalement la possibilité de définir des portées sur ces actions. Des développements sont donc prévus :

• Ajouter la portée (aka appartenance/scope) aux actions du CRUVED
• Supprimer la définition des portées de la configuration des sous-modules (propriété cruved dans module.json), car elle sera globale et générique au module Monitoring, comme c'est le cas dans les autres modules de GeoNature
• Suite à la gestion plus globale des sites et groupes de sites pour que ceux-ci soient multi-protocoles, ajouter un objet SITE et GROUP_SITE global (et leurs permissions disponibles). Si un utilisateur n'a pas de permissions dessus, je n'accède pas à la liste des sites
• Ajouter l'objet TYPE_SITES et ses permissions disponibles pour leur gestion dans le module ADMIN

[andriacap]

Salut,

Je rebondis sur le dernier messae de @camillemonchicourt .

• Une question a été soulevée les portées du CRUVED sur les visites impactent-ils les sites sur lesquels on peut associer des visites ?

Je pense que pour faire au plus simple c'est de ne pas surcoucher la logique métier en vérifiant le cas d'usage cité ci dessus. C'est à dire que si l'administrateur attribue des permissions d'édition et de suppression sur "mes données" pour les visites mais pas pour les sites, alors il ne pourra pas éditer ou supprimer les sites parents . Si on veut que ce soit le cas alors l'administrateur défini également les droits d'édition et de suppression sur "mes données" pour les sites .

• Autre point concernant les "observers" en champ libre (texte). Si l'on décide de définir des observateurs en champ libre (texte), les droits attribués pour ces cas ne concerne que l'utilisateur défini par l'id_digitiser.

[camillemonchicourt]

C'est à dire que si l'administrateur attribue des permissions d'édition et de suppression sur "mes données" pour les visites mais pas pour les sites, alors il ne pourra pas éditer ou supprimer les sites parents.

Dans ce qui est évoqué, la question du CRUVED C sur les visites ne concerne pas le fait de pouvoir modifier ou supprimer des sites, mais plutôt de s'appliquer sur les sites auxquels je peux associer un site.

---

Oui, comme dans Occtax, si les observateurs sont configuré en texte, alors pour la portée 1 on ne peux s'appuyer que sur l'id_digitiser.

[amandine-sahl]

Concernant l'implémentation du CRUVED, objet principal de cette issue, un point de vigilance à avoir quand à son implémentation est de ne pas opérer de duplication de code. Il faudrait que la méthode de récupération des données soit identique que l'on soit dans le gestionnaire de site ou dans un sous-module spécifique.

[andriacap]

Salut tout le monde,

Je me posais la question concernant les permissions au niveau des sous modules.

A l'heure actuelle il y a un decorateur qui s'éxécute avant chaque route pour vérifier que l'objet de permission existe et s'il existe de vérifier si l'object de permission est associé au module , dans ce cas il devient l'objet courant ( sinon se sera 'ALL' ) .

La question que je me pose par rapport à ça . Par exemple:

• L'administrateur associe des droits de suppression à un utilisateur en particulier, modification sur les visites pour un sous module en particulier (donc suivi_mortalite --> GNM_VISITE -> D et U =2 . Mes données)
• Concerant les droits de lecture pour l'objet GNM ol'administrateur se dit qu'il n'a pas besoin de les définir étant donné qu'il a défini les droits de lecture à "ALL" pour le module suivi_mortalite .

Qu'est ce qu'il prime cocnernant les droits entre le fait de ne pas avoir associé suvii_mortalite et GNM_VISITE mais d'avoir un suivi_mortalite / ALL / Lecture ?

Si c'est pas clair , on peut organiser un call / visio

Merci d'avance pour vos retours

[TheoLechemia]

je suis ça d'un peu loin, mais est-ce qu'on pourrait pas enlever le ALL sur monitoring ?

[andriacap]

je suis ça d'un peu loin, mais est-ce qu'on pourrait pas enlever le ALL sur monitoring ?

Tu veux dire le ALL sur les sous modules ? Car pour le MODULE_CODE : MONITORINGS il n'y a l'objet ALL que pour l'accès à MONITORING de manière générale et donc le fait de l'avoir ou non dans le menu et d'y accéder .

Pour les sous modules on a ALL/ GNM_(SITES_GROUP,SITE,VISITES ,OBSERVATIONS) CRUVED+ Portées

Pour MONITORINGS on a ALL(uniquement "R" et pas de portée) et GNM_(SITES et SITES_GROUP) + CRUDE + les portées

[amandine-sahl]

Je ne pense pas que ce soit une bonne idée de mixer les permissions ALL + GNM_XX ça reviendrait a faire de l'héritage ce qu'on l'on a cherché à supprimer.

Par contre je m'intérroge sur l'objet ALL au niveau des sous modules est-ce qu'il ne faudrait pas le supprimer et contraindre les administrateurs à définir les niveaux de droits pour chaque niveau.

[gildeluermoz]

Dans le cadre d'évolutions en cours de développement pour permettre la gestion des permissions au niveau des groupes de sites et des sites, le seul lien qui peut être fait en l'état du modèle de données, est d'utiliser le créateur et le digitizer pour appliquer un CRUVED et des filtres aux sites et groupes de sites. Cette approche mélange la notion d'identification de l'opérateur de saisie avec celle des permissions. Pour les groupes de sites, il n'y a que le digitizer d'enregistré, on ne peut donc pas vraiment l'utiliser pour gérer les permissions et créer des filtres. En effet si le digitizer est un administrateur en charge de la création de tous les sites et groupes de sites mais que les organismes qui produisent les visites ne doivent voir que les sites sur lesquels ils doivent intervenir, on ne peut pas le faire.

Pour gérer de manière homogène les droits et les filtres pour le CRUVED de ces 2 types d'objets qui sont en amont des visites et donc du lien qui peut-être fait avec les acteurs des JDD (le JDD est associé aux visites), est-ce qu'il ne faudrait pas envisager de calquer le mécanisme utilisé pour les acteurs des JDD. C'est à dire, une table cor_sites_actor et cor_sitegroup_actor, avec une colonne id_organism et id_role afin d'avoir toutes les possibilités de gestion des permissions sur ces objets.

Pour les fiches site.pdf, si, comme pour les JDD, il y a une colonne id_nommenclature_actor_role, ceci permettrait d'enrichir les informations sur qui fait quoi sur tel ou tel site ou groupe de sites . Ici, pas d'obligation de reprendre les nomenclatures des acteurs d'INSPIRE (financeur, maître d'ouvrage, point de contact pour les métadonnées, etc...) puisqu'il ne s'agit pas de métadonnées.

[camillemonchicourt]

Dans la 0.7.1, la gestion des permissions est définie pour chaque objet (sous-modules, groupes de sites, sites, visites) et l'objet ALL n'est plus pris en compte (#249). De fait les paramètres CRUVED des fichiers de configuration ainsi que permission object de module.json sont obsolètes. L'héritage entre les permissions sur le module Monitoring et ses sous-modules a aussi été supprimée à ce moment pour être plus explicite.

Dans la 0.8.0 (à venir), on a ajouté la prise en compte des portées sur les objets. Elles se basent sur ces champs des objets :

• Groupes de sites : id_digitizer
• Site : id_digitizer ou id_inventor
• Visite : id_digitizer ou observers
• Observation : id_digitizer

Pour être plus cohérent avec les choix retenus, cela mériterait d'évoluer vers :

• Visite : id_digitiser ou observers ou jdd
• Observation : id_digitizer ou hérité de la visite

Et comme indiqué ci-dessus par @gildeluermoz, des évolutions mériteraient d'être réalisées dans une prochaine version pour aller plus loin dans la gestion des portées des groupes de sites et sites.