Gestion des droits des utilisateurs - UsersHub / Keycloak

[Lilya-NS]

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 ?

• Est-ce qu'on reste sur UsersHub pour garder une homogénéité avec les autres applications (malgré toutes les contraintes liées à son utilisation) .
• Ou est-ce qu'il est prévu d'en changer sur les autres applis et dans ce cas là on peut opter pour une autre solution comme https://www.keycloak.org/ ? On l'a déjà utilisé sur plusieurs projets donc on sait que ça marche bien et que cela répond au besoin.

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

[camillemonchicourt]

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]

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

[Lilya-NS]

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]

Quelle est la demande ?

[Lilya-NS]

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]

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]

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]

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]

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]

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]

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]

J'apporte mon grain de sel. 🧂

---

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]

@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 :

• un schéma utilisateur et models SQLAlchemy simplifié avec un table utilisateur / groupes, géré avec Alembic
• des Auth Provider basé sur des standards : OAuth, OIDC, LDAP (en s'appuyant sur les libs dont tu parles)
• des méthode de réconciliation surcouchables avec le schéma utilisateur local
• des routes login / logout
• une gestion de l’authentification dans l'app hôte (avec Flask-Login)

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]

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