Chaque utilisateur peut faire partie de plusieurs CHATONS, aussi l’arborescence la plus logique semble être d’avoir une liste d’utilisateurs/utilisatrices (membres), et une liste de groupes (structure), chaque membre pouvant faire partie de plusieurs structures.
Droits d’accès
En comparant le forum et le site CHATONS, je m’attends à ce qu’il faille y avoir une gestion de droits : un membre d’un chatons peut vouloir avoir le blason de son CHATONS sur le forum, sans pour autant que les administrateurs de la structure veuillent forcément lui donner un accès en écriture aux fiches
Nextcloud, Wiki
Pour ces deux outils, a priori il n’y a pas de notion de groupe, donc un compte == un membre.
Les deux ont un module ldap facile à mettre en place
Si besoin, les deux ont quand même la possibilité de gérer la notion de groupe (par exemple, dossier partagé pour une structure ou page wiki réservée à une structure. Mais a priori ce n’est pas le but de ces outils) et faire un mapping automatique entre un groupe LDAP et un groupe interne.
Forum
Accès en tant que membre, notion d’appartenance à un groupe (blason)
Module d’authentification https://www.drupal.org/project/ldap_auth
Cette partie là demande un assez gros changement dans la façon dont c’est géré actuellement :
pour le moment, un compte == une structure (à quelques exceptions près)
Il faudrait avoir un compte par membre, et une fiche par structure, et qu’une personne puisse éditer les fiches des structures auxquelles elle appartient.
(Je ne connais pas assez bien drupal pour savoir ce qu’il est possible de faire : à première vue, on chercherait un mapping user = membre et rôle = groupe LDAP, mais peut être qu’il est possible de tenir compte de la notion de groupe LDAP sans utiliser les rôles pour ça)
Difficulté supplémentaire : il y a actuellement un rôle « traducteur », qui peut très bien être tenu par un non-membre.
Réflexions / Aspects pratiques
Lieu d’hébergement du serveur LDAP ?
Nécessité d’entrer à la main les nouveaux users (ou les CHATONS) par un « admin » ldap (pas de création autonome).
Avantage : un seul endroit pour tous les outils
Inconvénient : La meilleure interface que j’aie trouvée de LDAP est phpLdapAdmin et elle est franchement pas géniale.
Possibilité de faire des scripts ou des page ad hoc pour gérer les utilisateurs ou groupes
Demande un peu de développement
Permet d’avoir un lieu centralisé comme « base de vérité » sur les membres du collectif
Demande de précision : entre les candidats chatons, les traducteur⋅ices, les personnes qui viennent poser des questions sur le forum ou alimenter le wiki, on a quand même sur presque tous les outils des comptes de personnes qui ne sont pas membres du collectif. Est-ce qu’il est possible de mettre en place une authentification unique sur tous ces outils, sans pour autant supprimer la possibilité de créer un compte hors ldap ? (désolée si la question est naïve, mais je n’y connais rien).
Notre logique de fonctionnement est mélangée dans le code, d’où la proposition de fork
L’outil est testé uniquement sur notre serveur LDAP, bottin, et non sur openldap ou 389. C’est certain qu’il faudra patcher des trucs, par exemple, bottin ne gère pas les schemas, c’est sûr du coup qu’on oublie des champs required.
La qualité du code n’est pas optimale. Ayant une petite base d’utilisateur, nos requetes chargent souvent toute la base utilisateur en RAM. On a jugé que jusqu’à ~1000 utilisateurs c’était un comportement censé mais au delà ça peut poser problème.
Je ne serais pas surpris que l’interface de keycloak soit suffisante et accessible, et même que d’autres outils de SSO fournissent une interface graphique acceptable. Je note aussi que 389, le serveur d’authentification de Red Hat, a au moins 2 interfaces, dont une récente pour cockpit : https://www.youtube.com/watch?v=F9F01XX-rd0
Enfin, je me demande à quel point une solution beaucoup plus simple où LDAP/OpenID Connect serait utilisé seulement pour l’authentification dans un premier temps, tout en laissant la gestion des autorisations à chaque logiciel à la main. Ou dans un modèle un peu plus complexe, encodé comme logique métier dans le service d’authentification uniquement l’adhésion au collectif ou non. Pour Nextcloud, il suffirait alors juste de mettre dans la requête LDAP que le user doit être membre du collectif pour se connecter.
Ça va dépendre de l’outil. pour le forum et pour le wiki c’est possible de mélanger les comptes LDAP et les comptes non-ldap. Pour Nextcloud c’est un peu casse pieds, mais c’est faisable aussi. Pour Drupal je ne sais pas.
Note cependant qu’il est tout à fait possible de créer un compte LDAP (authentification unique) pour un non-chatons, en donnant des droits spécifiques via ce compte LDAP (traducteur, wiki, etc.). Ça demande juste un peu de réflexion pour ne pas se perdre dans les spécificités.
Je travaille sur plusieurs logiciels libres autour des annuaires LDAP comme LemonLDAP::NG ou LDAP Tool Box. Pour un déploiement sous forme de conteneurs, regarder le projet FusionIAM (https://fusioniam.org)
Salut. Chez Yaal Coop on développe Canaille, qui est un serveur d’identité OpenID Connect qui se branche sur un serveur LDAP. On l’utilise en interne, pour nubla (notre candidat CHATONS) et quelques autres projets.
C’est écrit en python, ça utilise flask et authlib, et on est absolument ouvert aux contributions La page gitlab indique que le projet n’est pas encore stable, mais ça fait 18 mois qu’on l’utilise en production sur plusieurs bases utilisateurs et pour le moment tout se passe très bien (la plus grosse étant celle de supercoop avec 1500 utilisateurs.
Pour le moment le seul backend disponible c’est LDAP (c’est testé avec OpenLDAP mais pas avec 389) mais on aimerait très fort savoir se brancher sur d’autres bases de données. L’avantage d’avoir canaille sur un LDAP c’est qu’on peut faire de l’OIDC là où c’est disponible (ça permet d’avoir de l’authentification unique et de simplifier l’expérience utilisateur) et là où OIDC n’est pas disponible il reste toujours LDAP qui reste supporté à peu près partout.
Les fonctionnalités de canaille c’est :
Gestion de profils utilisateurs
Gestion de groupes d’utilisateurs
Un système de permissions assez simple (qui a le droit de voir/éditer quels champs sur son profil, qui a le droit de consulter/modifier le profil des autres etc.)
Système de mail de réinitialisation de mots de passe, système de mail d’invitations
Authentification unique avec OpenID Connect
On a réussi à brancher canaille avec succès à dovecot, roundcube, humhub, element/synapse, glitchtip et aussi à nextcloud, d’ailleurs on a repris il y a peu la maintenance de nextcloud-oidc-login (une application nextcloud pour l’authentification unique avec OIDC).
Si le projet est pertinent, on est assez motivés pour collecter les besoins des chatons, fournir du support (notre documentation d’installation n’est pas du tout à jour, et on le sait ), au mieux développer des fonctionnalités ou sinon organiser le développement avec la communauté.
Il y a une démo en ligne, les instructions de connexion sont dans le README du projet.
L’interface utilise fomantic-UI mais canaille est thèmable donc quelqu’un de motivé pourrait utiliser autre chose. Ça ressemble à ça :
Oui. nextcloud-oidc-login permet au utilisateurs d’un nextcloud de s’authentifier via un fournisseur d’identité externe, comme par exemple canaille.
Il faut configurer Canaille pour lui indiquer les accès au serveur LDAP, et où et comment lire les informations sur les utilisateurs et les groupes. Ça se passe dans la configuration de canaille.
La plus grande difficulté actuellement réside dans le fait que Canaille utilise un LDAP pour enregistrer les informations relatives à OIDC (les tokens de connexion etc.). Et donc pour ça il est nécessaire d’installer les schémas correspondants dans le serveur LDAP, ce qui peut s’avérer pénible.
J’aimerai bien qu’on avance sur ce sujet et j’ai donc mis un point à l’ODJ de la réunion mensuelle de demain : est-ce que certains d’entre vous y seront pour discuter les pistes évoquées ici ?
Je souhaite également ouvrir les choix envisagés à OpenID (via plugin nextcloud par exemple).
La question de YunoHost se pose aussi car ynh présente l’avantage d’avoir de l’authentification unique native après l’installation d’une app, ce qui simplifie pas mal de réglages.
), au mieux développer des fonctionnalités ou sinon organiser le développement avec la communauté.
