search

PnX-SI / GeoPaysages

Application web permettant de publier un observatoire photographique des paysages
GNU General Public License v3.0
11 stars 8 forks source link

Gestion des droits des utilisateurs - UsersHub / Keycloak #162

Open Lilya-NS opened 1 year ago

Lilya-NS commented 1 year ago

Dans le cadre de la prestation Multi-observatoires avec le SIT PACA, il est question d'ajouter une solution pour la gestion des droits des utilisateurs.

La question du jour : Quelle solution choisir ?

Qu'en pensez-vous @camillemonchicourt @TheoLechemia @mvoundy @Chrispnv @xavyeah39 ?

camillemonchicourt commented 1 year ago

On souhaite basculer progressivement vers un mécanisme plus standard de gestion des utilisateurs et d'authentification et ne plus (forcément) utiliser UsersHub. Mais il ne s'agit pas non plus d'imposer une autre solution comme KeyCloak mais de s'appuyer sur des méthodes plus classiques et standard avec Oauth notamment, permettant alors d'utiliser KeyCloak par exemple. KeyCloak serait d'ailleurs certainement la solution suggérée par défaut, mais ça pourrait être autre chose.

mvergez commented 1 year ago

Cela a été un peu discuté ici : https://github.com/PnX-SI/GeoNature/issues/1811, avec les mêmes conclusions que @camillemonchicourt

Lilya-NS commented 1 year ago

D'accord, merci à vous deux @mvergez et @camillemonchicourt ! Dans ce cas il faudrait voir comment la demande du SIT PACA sur GeoPaysages peut aller dans ce sens.

camillemonchicourt commented 1 year ago

Quelle est la demande ?

Lilya-NS commented 1 year ago

Quelle est la demande ?

"Il est demandé de développer dans l'interface d'administration un module permettant une gestion plus fine des droits par groupes d'utilisateurs et/ou organismes. Ceci afin de permettre l'attribution de droits de différentes portées sur les sites selon le groupe de l'utilisateur et les observatoires ratachés.

Il est donc envisagé d'implémenter une relation entre rôles et obsservatoires.

Exemple : un utilisateur du groupe PNR LUBERON ne peut accéder qu'à la gestion des sites (create, update, delete) du ou des observatoires rattachés à son rôle ou son groupe."

camillemonchicourt commented 1 year ago

A analyser et affiner, mais actuellement dans UsersHub chaque utilisateur est associé à un organisme. Il serait certainement plus pertinent d'associer chaque observatoire à un organisme, plutôt qu'utilisateur par utilisateur. Ainsi on n'aurait pas à associer manuellement à un observatoire chaque nouvel utilisateur. Le fait de l'associer à un organisme, elle-même associée à un observatoire serait suffisant et plus pertinent.

Attention cependant, ça reste une vision assez spécifique liée au contexte spécifique des PNR PACA, donc attention à ne pas compliquer l'utilisation et de ne pas imposer la nécessité d'associer chaque utilisateur à un observatoire.

Surtout que je reste toujours assez prudent sur la pertinence d'ajouter plein de limites et de droits. Au final, je ne suis pas convaincu de l'intérêt de compliquer et de limiter les droits dans l'Admin, ni qu'un Admin d'un PNR ait un réel risque de modifier des contenus d'un autre PNR. Donc si c'est développer, à ne pas imposer aux autres, à mettre en place de manière générique et à ne pas activer par défaut.

Lilya-NS commented 1 year ago

Bonjour !

Du nouveau sur le sujet PnX-SI/GeoNature/issues/1811 ? @camillemonchicourt

Concernant tes retours, effectivement il faut que l'on fasse au plus simple. Le fait d'associer les utilisateurs à un organisme et d'associer l'organisme à l'observatoire semble le plus logique !

camillemonchicourt commented 1 year ago

Oui on a testé le fonctionnement dans un nouveau projet avec succès et satisfaction : https://github.com/PnEcrins/istSOS-import#authentication

Donc l'idée est toujours la même, de remplacer UsersHub petit à petit par une solution d'authentification plus standarde, générique et robuste.

Pas planifié ni financé au niveau de GeoNature, mais c'est un sujet indépendant et à part. On commence à mettre en place cette nouvelle solution dans nos nouveaux projets.

xavyeah39 commented 2 months ago

Cela n'a pas été priorisé dans les devs de la v1.3.0 . Mais le sujet est plus que jamais d'actualité car la dépendance UHAM n'évolue pas au même rythme que GeoPaysages et impose une veille régulière pour éviter un trop grand delta. A mon sens il faudrait basculer vers une autre solution d'authentification s’appuyant sur des protocoles plus standards pour s'affranchir de la dépendance à UHAM. UHAM est récemment passée sur Flask 3 (versions > 2.0.0) alors que GeoPaysages est toujours en 2. La dépendances à UHAM a donc été fixée en version 2.0.0 dans les requirements de GeoPaysages (car il a déjà fallu faire des correctifs pour la compatibilité avec la v2.0.0).

Il me semble qu' @Arnoul serait bien intéressé pour les PNR PACA 😉 Affaire à suivre donc !

TheoLechemia commented 2 months ago

Hello,

On est en train de prévoir un v3 de UHAM (oui encore !) qui s'appuierais sur des protocoles standards : OAuth, OIDC, LDAP. L'idée est de pouvoir se passer complètement de UsersHub pour pouvoir brancher nos outils sur des systèmes d'autentification externe. On pense à KeyCloak, Active Directory ou que sais-je ! Mais par contre la brique UHAM elle resterais pour indispensable pour pouvoir connecter nos Geo-bidules à ses système d'authentification externes

20cents commented 2 months ago

Petite piste de réflexion : A NS on n'envisage plus de gérer les users à la mano. On est sur KeyCloak, mais peut importe. En revanche pour les droits, je préfère les gérer dans l'app car ils dépendent du contexte métier, ex. avec Geopaysages : Il faudrait des administrateurs par observatoire. Les observatoires étant créés dans l'admin de Geopaysages, il faudrait les faire remonter dans l'outil de gestion des utilisateurs pour pouvoir associer user / observatoire / role. C'est moins compliqué de faire descendre la listes des users dans l'app, même si ça donne l'impression de re-coder la partie gestion des droits.

babastienne commented 2 months ago

J'apporte mon grain de sel. :salt:

la brique UHAM elle resterais pour indispensable pour pouvoir connecter nos Geo-bidules à ses système d'authentification externes

Je ne suis pas sur de bien comprendre pourquoi ? Pourquoi ne pas tout simplement intégrer des connecteurs OIDC/LDAP dans les diverses apps Geo ? Généralement il existe des libs dédiées dans l'écosystème flask/django qui font très bien le taf' et ça éviterai d'avoir une dépendance à maintenir en plus avec UHAM, non ?

En revanche pour les droits, je préfère les gérer dans l'app car ils dépendent du contexte métier

J'ai l'impression que y a deux sujets en parallèle sur ce ticket : la gestion de l'authentification (principe des protocoles OIDC pour authentifier un individu) et la gestion de l'autorisation (titre du ticket -> gestion des droits). Généralement les sujets sont traités quasi simultanément dans des outils qui centralisent tout (par exemple keycloack gère à la fois l'identification, l'authentification et l'autorisation) et c'est souvent plus simple comme ça. Séparer l'authentification et l'autorisation c'est possible mais il faut faire attention à ce que ce soit clair en terme de périmètre pour ne pas faire une machine un peu floue. Dans cette hypothèse ça implique que la brique qui gère l'authentification et l'identification (keycload, annuaire ldap ou whatever) ne connait aucune information sur les droits des profils gérés, pas même les admins, et que tout est géré dans les briques associées, individuellement. Ca peut vite être redondant quand on commence à avoir pas mal de briques dans le système mais c'est souvent plus simple à implémenter.

TheoLechemia commented 2 months ago

@babastienne oui tu as raison il existe bien des libs Flask pour faire du OIDC et autre "auth provider". Mais elles nécessitent toutes de les intégrer à son app, d'écrire un mécanisme de réconciliation avec sa base "utilisateurs", d'avoir une route /login /logout, de gérer un mécanisme de gestion de session etc... L'idée de cette petite lib est de simplifier tout ce mécanisme et en gros elle fournira :

Dans Django, c'est beaucoup plus integré et on a pas besoin de la plupart de ces briques et il suffit de rajouter les Authentication Backend.. dans Flask, il y a un peu plus de taf !

Mais rien n'oblige GeoPaysages de l'utiliser et de se baser directement sur une lib OIDC ou autres. ça nécessitera juste de réimplémenter certains mécanisme décrit plus haut

NaturalSolutions-Victor commented 2 months ago

Bonjour à tous,

Nous avons eu ce matin une discussion avec @Arnoul des PNR Sud sur le sujet. De leur côté ils expriment le besoin de développer cette fonctionalité. L'objectif est de sortir d'un modèle où tous les utilisateurs ont les droits sur l'ensemble des entités de parc.

Après discussion technique avec @20cents , il semblerait qu'on s'oriente vers une solution keycloak qui permettrait de gérer les utilisateurs depuis keycloak et leurs droits depuis l'interface de Géopaysage. Ce fonctionnement permet aussi que keycloak ne soit pas imposer et que d'autres outils puissent être utilisés. Un devis sera généré dans les prochains jours.

Nous avons bien noté l'importance de ne pas rendre cette option obligatoire pour les autres utilisateurs qui n'en ont pas besoin et donc de la cohabitation entre les instances sous Keycloak et celles encore sous Userhub pour ne pas obliger tout le monde à mettre à jour son Géopaysage.

@20cents pourra vous donner des détails si besoin

Bonne journée