Réflexion sur lien NextCloud/Paheko

[jeanlucM]

Bonjour à tous, ça répond dur. On voit que @tcit est de retour de vacances (salut à toi mon pauvre, moi je démarre ). Je lance une réflexion en présence du plus balèze du groupe.

On a vu ces dernières semaines des problèmes pour aller de NextCloud à Paheko suite à priori à la dernière MAJ.

Pourtant, chacun est installé de son côté : https://xxxxx.frama.space/ pour l’un et https://xxxxx.paheko.frama.space/ pour l’autre (on le voit en ouvrant un nouvel onglet depuis le Paheko de NC).

En fait, ils ont leur URL, leur code, leur base de données, leur logique (multi-groupes côté NC et mono-catégorie côté Paheko, …) et fonctionnent parfaitement en autonome ailleurs.

Ma crainte est que ces problèmes de lien détournent certains de l’usage de l’un ou de l’autre (redoutant de perdre les accès à des données précieuses de chaque côté😨).

Ce serait dommage tellement ces 2 logiciels sont un vrai plus pour une association (NC pour la collaboration du bureau et des bénévoles, Paheko pour gérer les membres et les euros). Et encore grand merci à Framasoft pour cela .

Bien les séparer éviterait les effets non désirés. Si bug il y a, on cherche côté concerné et pas dans le lien. Et cerise sur le gâteau pour Paheko, on se serait sur un fonctionnement type https://xxxxx.paheko.cloud/, plus facile de trouver dans de l’aide dans le forum.

Comme expliqué ici, , proposition d’avoir :

• Uniquement à la création d’un compte NC, création d’un compte Paheko. Identifiant =mail Paheko (1) = mail NC (2) et mot de passe Paheko = mdp NC.
• Par défaut, catégorie cachée sans fonctionnalité (3). Mais si du groupe NC « admin », alors placé dans catégorie Paheko « administrateurs » (4).
• Un accès systématique à « Paheko » depuis NC (icône en base). Lors du clic, se lance dans un nouvel onglet avec sa propre URL : identifiant/mail = celui de NC et mdp= celui de NC (5).

(1) RISQUE DE BUG : on peut actuellement modifier dans Paheko, le champ utilisé comme identifiant de connexion !

(2) A la création, si le mail est déjà existant dans Paheko, message d’alerte pour changer côté NC ou supprimer le membre côté Paheko.

(3) Les droits de départ (rien) pourront évoluer au gré de l’affectation aux catégories ajoutées.

(4) Si on a perdu tous les accès Paheko, on recrée un compte NC « admin », ce qui donne un compte Paheko « administrateurs » et on met à jour ce qui a besoin de l’être.

(5) Si le mdp a été modifié dans NC ou dans Paheko ; on aura cet écran. On le saisit ou on utilise la fonction « mot de passe perdu ».

Et c’est tout . Les droits, modifications, suppressions, …, sont gérés de chaque côté sans répercussion sur l’autre. C’est plus basique, mais plus solide.

Bref, d’avoir 2 applis indépendantes, accessibles sur leur propre URL, avec leurs identifiants, plus proche de leur base, avec des fonctionnalités limitées vis-à-vis de leurs cousines (ex pas d’autres applis pour NC, ex pas de site Web pour Paheko …), cela permet d’évoluer avec le temps sans interférer sur l’autre😉.

A dispo pour en discuter les amis, Jean-luc

[nicotentin]

Je n’ai pas assez d’expertise sur ces applications pour dire si la proposition est la meilleure, mais je suis d’accord sur le diagnostic de la situation actuelle insatisfaisante.

[bohwaz]

La problématique est complexe.

Je ne sais pas ce qu’en pense @tcit, mais je pense que l’idéal serait :

1. Que la gestion des droits dans Paheko soit désactivée : il y aurait encore des catégories, mais on ne pourrait plus leur affecter des droits (ça c’est facile) :

   

2. Que Paheko ne permette pas de se connecter en dehors de NC (facile aussi).

3. Que Paheko ne permette plus de gérer les mots de passes des membres (vu que ça ne serait plus utile du coup) (facile aussi).

4. Que l’interface des utilisateurs NextCloud permette de définir pour chaque groupe d’utilisateurs NextCloud quels droits ça donne dans Paheko (pas facile)

Ainsi c’est NC qui dicte quels sont les droits de la personne connectée, et on n’utilise Paheko que comme une « base de données des membres », qui peut être déconnectée de la liste des utilisateurs de NC, et on laisse la gestion des droits à NextCloud, ce qui ferait plus de sens et éviterait de la confusion et des bugs :

• plus de souci si on change l’identifiant de connexion, car on ne pourra plus configurer l’identifiant de connexion
• pas besoin de maintenir une synchro entre les comptes NC et les membres Paheko
• pas de confusion dûe au fait que Paheko permette de gérer des droits, des mots de passe, alors qu’en fait c’est NextCloud qui compte.

Les problématiques que ça poserait :

• si on exporte la BDD Paheko vers un autre hébergeur Paheko, la BDD n’aura pas d’utilisateur avec un mot de passe, et aucun groupe permettant de se connecter / être admin, donc on aura importé la BDD mais on sera “à la porte” mais ça c’est détectable et réglable côté Paheko, par exemple en créant automatiquement un nouveau membre « admin » dans une nouvelle catégorie « admin » dans ce cas
• on perd la possibilité de donner un accès au Paheko aux membres qui n’ont pas accès au NextCloud de l’asso, mais je pense pas que ça soit un gros souci ?
• ça oblige à re-créer un membre Paheko pour chaque adhérent⋅e de l’asso, même s’iel a déjà un compte NC.
• il faudrait développer un plugin/patch NextCloud (?? je connais pas le fonctionnement de NC à ce niveau) pour permettre d’indiquer les droits Paheko de chaque groupe NC, potentiellement pas trivial selon la complexité de NC…

J’en oublie peut-être.

Tu en pense quoi @tcit ? Je peux implémenter la partie Paheko assez facilement.

[jeanlucM]

Bonjour à tous, dans ma réflexion ci-dessous, je pars de l’hypothèse que Framaspace = un NC limité + un Paheko limité. Mais qu’une fois à l’étroit, l’asso peut aller ailleurs pour +de Go, + d’utilisateurs, + de fonctions de chaque côté…

La solution retenue ne devrait pas être propre à Framaspace mais susceptible d’être transposée. Je me suis inspiré des derniers devs de BohwaZ et des articles récents de la contre voie sur le SSO et la fabrique de service (super intéressant).

Une fois dit cela, la question est presque philosophique (la technique suivra dans tous les cas ), 3 scénarios sont possibles :

1. Paheko est une sous-application de NC (comme le sont les autres apps). C’est presque le cas actuel, mais il faudrait en plus les fonctionnalités décrites au-dessus par Bohawz. Cela demande beaucoup de synchro compte <=> membre. Également de s’assurer qu‘une fonction qui existe déjà sur NC est bien désactivée dans Paheko, sinon on s’y perd.
Les évolutions de l’un doivent se faire avec les évolutions de l’autre, il a risque de bug.
Et les limites de l’un s’appliquent à l’autre (nb membres paheko = nb utilisateurs NC)
L’imbrication est faite par du dev propre à Framaspace

2. Paheko est à côté de NC (sur le même serveur avec des échanges direct par code). On fait en sorte que les comptes de NC soient présents dans Paheko ;
Qu’il y a bien des admins de chaque côté (pour faire simple, cela peut être les mêmes).
Chacun doit pouvoir évoluer sans impacter l’autre, on limite au maximum l’interaction pour éviter les bugs (c’est à cette solution que j’avais pensé au départ).
La synchro est faite par du dev propre à Framaspace

3. Paheko et NC sont distincts (ils peuvent être proches ou éloignés). On utilise une couche standardisée (en l’occurrence OIDC). NC est configuré pour fournir les identités et Paheko en client émet une demande d’accès.
NB : On peut imaginer que hors Framaspace, le fournisseur d’identité soit autre que NC (qui pourrait être lui aussi client) et que Paheko en 2eme client échange avec ce fournisseur, tout ça sur les mêmes bases fonctionnelles.
Peu de dev côté NC (a), un peu plus côté Paheko (b). Les tests sont faciles à faire (voir en bas de OIDC et Paheko ).

(a) Côté NC : En base avec l’app OIDC , on peut limiter les groupes qui accordent des jetons et certainement d’autres choses à creuser (Nicolas est sur le coup).
A faire en + de l’install de l’app sur chaque Framaspace, déclarer un client par CLI avec l’URL de retour adhoc vers Paheko.

(b) Côté Paheko, déclarer dans le config.php les constantes url et keys qui vont bien. Pour les Framaspaces existants avec les comptes et membres déjà présents de chaque côté, cela devrait marcher tout de suite. Pour les autres, il faut développer la fonctionnalité de création de membre côté Paheko (je vais des propositions à BohwaZ dans ce sens).

En résumé, le scénario 1), en théorie c’est bien, en pratique, c’est compliqué. Le 2) on oublie car ni vraiment 1), ni vraiment 3). Le 3) le plus solide/vérifiable/transposable, mais il y a encore à développer.

Bonne journée à tous, Jean-luc

[tcit]

Salut !

On avait eu pas mal de problèmes avec l’utilisation simple de Paheko\LOCAL_LOGIN en fournissant depuis Nextcloud simplement le nom et les permissions de l’utilisateur. En effet, de multiples opérations comme la clôture d’un exercice nécessitent un ID utilisateur, et donc cela plantait avec un utilisateur virtuel (j’ai pas suivi si ça a changé depuis).

À la place, on a donc créé des utilisateurs Paheko classiques via l’API, et associé leur ID avec chaque utilisateur Nextcloud. Ça nécessite notamment que l’utilisateur framadmin reste admin côté Paheko afin de pouvoir opérer l’API ainsi.

Sauf que si des gens modifient les utilisateurs côté Paheko, les associations sont complètement bouleversées, et on se retrouve dans la situation actuelle.

Comme proposé par @jeanlucM , partir sur OIDC me semble en l’état la solution la plus propre, en évitant des bidouilles de notre côté.
Néanmoins, cela nécessite de pouvoir régler les permissions pour chaque groupe OIDC dans la configuration de Paheko, et que les utilisateurs ne puissent pas toucher aux permissions à ce niveau.

Le cas d’usage d’avoir des utilisateurs classiques non gérés dans la source OIDC/Nextcloud me semble toujours pertinent en revanche.

Cela étant dit, cela nous n’avons pas eu le temps d’étudier davantage la question, donc ce qui peut sembler une bonne idée à l’échelle individuelle peut être plus compliqué à l’échelle de Framaspace (création et déploiement de la configuration côté Paheko et Nextcloud OIDC). Dans tous les cas, c’est hélas un chantier conséquent.

[bohwaz]

@tcit

En effet, de multiples opérations comme la clôture d’un exercice nécessitent un ID utilisateur, et donc cela plantait avec un utilisateur virtuel (j’ai pas suivi si ça a changé depuis).

Ça c’est des bugs, faut les remonter pour qu’ils soient corrigés, au lieu des les contourner et se créer des soucis

(bon normalement celui-là c’est bon )

@tcit

Néanmoins, cela nécessite de pouvoir régler les permissions pour chaque groupe OIDC dans la configuration de Paheko, et que les utilisateurs ne puissent pas toucher aux permissions à ce niveau.

C’est pas très compliqué à faire, mais en pratique je ne sais pas comment on peut faire car OIDC ne comporte pas de notion de permissions, ce qui complexifie les choses. N’étant pas utilisateur d’OIDC et n’ayant pas reçu de retour à ce sujet, je ne peux pas avancer

Peut-être qu’il faudrait permettre de définir dans le config.local.php un callback qui serait appelé à la connexion OIDC, et qui pourrait modifier les permissions de l’utilisateur connecté en fonction de ce qui a été renvoyé par le serveur OIDC.

Un truc du genre :

function oidc_login_callback(User $user, stdClass $oidc_data)
{
  if (in_array('paheko_compta', $oidc_data->groups)) {
    $user->setPermissions([Session::SECTION_ACCOUNTING => Session::ACCESS_ADMIN]);
  }
}

Pas très compliqué à faire en pratique.

Est-ce que ça te conviendrait @tcit ?

Et du coup désactiver la gestion des permissions dans Paheko.

[tcit]

@bohwaz

C’est pas très compliqué à faire, mais en pratique je ne sais pas comment on peut faire car OIDC ne comporte pas de notion de permissions, ce qui complexifie les choses. N’étant pas utilisateur d’OIDC et n’ayant pas reçu de retour à ce sujet, je ne peux pas avancer

Je pensais juste à une configuration déclarative du genre :

const OIDC_CLIENT_GROUP_PERMISSIONS_MAPS = ['admin' => [Session::ACCESS_ADMIN, Session::ACCESS_ACCOUNTING], 'compta' => [Session::ACCESS_ACCOUNTING]];

[bohwaz]

Dans mon souvenir les groupes ne font pas partie de la spéc OIDC, donc même si NC les renvoie, ça ne dit pas qu’un autre serveur OIDC renverra ce genre d’info, mais peut-être plutôt d’autres types de scopes ou claims.

Donc je pense qu’un callback est plus adapté à la variété de serveurs OIDC.

Et ça peut aussi permettre de créer l’utilisateur à la volée s’il n’existe pas si tu veux avoir ce genre de comportement dans certains cas

[jeanlucM]

Bonjour à tous,

Le serveur OIDC de NC renvoie les groupes dans 2 portées (scopes) avec les mêmes valeurs, « roles » et « groups » . Je vous liste le contenu complet d’un jeton :

{
  "iss": "https://url_NC",
  "sub": "mail du compte",
  "aud": "Identifiant du client",
  "exp": "aaaaaaa",
  "auth_time": "bbbbbb",
  "iat": "ccccccc",
  "acr": "0",
  "azp": " Identifiant du client ",
  "preferred_username": " mail du compte ",
  "scope": "openid profile email roles groups ",
  "nbf": "dddddddd",
  "jti": "fff",
  "roles": [
    "groupe1",
    "groupe2",
    "groupe3"
  ],
  "groups": [
    "groupe1",
    "groupe2",
    "groupe3"
  ],
  "updated_at": "eeeeeee",
  "name": "prenom et nom du client",
  "family_name": "nom du client",
  "given_name": "prénom du client",
  "middle_name": "",
  "picture": "chemin vers la miniature",
  "quota": "X GB",
  "email": " mail du compte ",
  "email_verified": false
}

« roles » a l’air plus commun dans OIDC que « groups », à vérifier dans des jetons fournis pas d’autres serveurs OIDC autre que NC. Si confirmé, c’est celui-ci qu’il faut utiliser. Ne change rien pour la suite.

[jeanlucM]

Pour le fonctionnement, j’irais sur qqchose de différent.

On est d’accord que si OIDC_CLIENT_MATCH_EMAIL = true et que le mail du compte NC correspond au mail d’un membre côté Paheko, Paheko s’ouvre avec le menu correspondant à la catégorie du membre sélectionné. Je propose de garder ce fonctionnement

Pour la partie création de compte côté Paheko, est ce que l’on pourrait avoir les constantes suivantes :

OIDC_CLIENT_CREATE_ACCOUNT = true ou false
et
OIDC_CLIENT_MAPPING_GROUP_CATEGORY = [‹ admin › => ‹ Administrateur ›, ‹ compta › => ‹ Trésorier.ière ›, « membre » => ‹ Membres actifs ›]; NB : j’ai mis les noms de catégorie en français, à modifier

Ce qui donnerait le fonctionnement suivant :

Si OIDC_CLIENT_MATCH_EMAIL = true et OIDC_CLIENT_CREATE_ACCOUNT = true

1. Si le mail NC est trouvé côté Paheko, pas de création nécessaire et Paheko s’ouvre avec la catégorie du membre

2. Par contre, si pas de mail trouvé, création d’un compte Paheko avec :
   « Adresse email » Paheko = « E-mail » NC
   « Nom et prénom » Paheko = « Nom du compte » NC
   « Mot de passe » Paheko = suggestion choisie au hasard par Paheko

Si d’autres champs sont obligatoires, ils doivent avoir une valeur par défaut.
Si pas le cas, refus de création de connexion et message d’alerte.

Puis pour la catégorie :
« Catégorie » Paheko" = 1er « Groupe » trouvé dans la constante OIDC_CLIENT_MAPPING_GROUP_CATEGORY, on ne regarde pas les suivant. L’ordre dans est donc important, je m’explique :

Si dans groupe « admin » => catégorie « Administrateur » même si aussi dans groupe « compta » et/ou groupe « membre »
Si dans groupe « compta » => catégorie « Trésorier.ière » même si aussi dans groupe « membre »,
etc
Si aucun des groupes n’est trouvé dans la constante, « Catégorie par défaut des nouveaux membres »

[jeanlucM]

Bonjour à vous, je vous faire part de mes recherches :

Côté serveur NC OIDC (app officielle listée dans la doc NextCloud)

MAJ semaine dernière en V1.12 avec le support des wilcards dans les redirections (ça c’est top car répond à mon besoin évoqué avec BohwaZ et pourrais servir pour Framaspace):

End of path wildcard support (…/*) , Port wildcard for localhost (e.g. http://localhost:*) et
Subdomain wildcard support (e.g. https://*.example.com/callback) mais pas en base, à activer via occ.

Également ajout de l’attribut “offline_access» pour être conforme à « OpenID Connect Core 1.0 specification », Nicolas n’a pas encore regardé l’effet sur le lien NC/Paheko, mais de toute façon désactivable.

Côté client NC OIDC

J’ai lu les articles de contre voie sur leur SSO et leur fabrique à services (5 => NextCloud, WorPress, Paheko, ListMonk, Peertube). J’ai échangé avec Neil pour en savoir plus sur les clients OIDC utilisés (leur serveur OIDC est KeyCloak), super intéressant.

Pour NC, c’est l’app officielle aussi user_oidc (gestion par constantes uniquement).
Pour WordPress, c’est ce plugin openid-connect-generic (basique, mais surtout compatible WP multisite).
Pour listeMonk, config expliquée ici. Pour Peertube, plugin présenté ici.

Pour Paheko, pas d’OIDC, ils utilisent le LOCAL_LOGIN avec des ajustements (la fonction OIDC n’existait pas au moment du dev de leur fabrique. Intéressé par toute évolution ).

Ma proposition pour Paheko

Comme l’a déjà fait @BohwAZ, il est mieux de se limiter à 2 manières de se connecter,

Soit via l’utilisateur virtuel (LOCAL_LOGIN avec tableau), induit des limitations et des risques car il n’est personne et tout le monde à la fois. Mais c’est basique et solide.

Soit via mapping OIDC en cherchant un fonctionnement complet comme les autres clients OIDC ci-dessus (connexion, création, voir mise à jour pour certains), ceci quel que soit le serveur OIDC (on se basera sur NC et Keycloak, c’est déjà pas mal). Il ne manque pas grand-chose pour assurer le minimum.

Une fois que l’on aura montré que ça marche, @tcit choisira (ou restera sur le cas intermédiaire du lien en paseto).

Je vais faire des propositions sur la liste dev@paheko.cloud en rappelant mon besoin de départ (1 NextCloud multi section/groupe d’un omnisport + 1 Wordpress multisite + 1 Paheko multisite). Bonne soirée à tous, Jean-Luc