Authentification unique pour les outils des CHATONS

Lors du dernier camps CHATONS a été demandée la possibilité de mettre en place une authentification unique pour les outils utilisés par les CHATONS.

Je démarre donc la discussion, avec les informations que j’ai collectées pour le moment

Sites concernés

Arborescence prévue

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)

Site/Fiches CHATONS

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

(cc @pyg @Angie @ljf )

1 Like

Merci Immae d’avoir analysé cette possibilité.

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).

C’est clairement et malheureusement la seule interface ldap , et en effet, pas géniale.

Peut être une gestion via keycloak serait-elle possible ?

On a codé notre interface web qui se repose uniquement sur un serveur LDAP pour nos besoins. Elle ressemble à ça :

En cliquant sur « Créer un nouveau compte directement » :

En cliquant sur « Explorateur LDAP » :

il est possible de forker le repo ici : Deuxfleurs/guichet: Interface web pour gérer le LDAP: changer son mot de passe, ses infos de profil, inviter des gens, administration - guichet - Gitea: git with a cup of coffee
Mais quelques avertissements :

  • 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 note aussi l’existence de Hiboo développé par TeDomum, qui n’est pas qu’une interface mais un serveur OpenID Connect standalone : Hiboo, ré-inventons la roue de l'authentification — TeDomum

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.

Voilà, my 2 cents :slight_smile:

Ç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.

Merci Quentin,
guichet peut effectivement servir de base pour une interface un peu user-friendly à un service LDAP. À voir au moment venu du coup :slight_smile:

Bonjour,

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)

Je serai ravi d’aider les chatons sur ce sujet.

À bientôt,

Clément.

Ça tombe bien, il n’est pas envisagé d’avoir des comptes sur le NC pour des non-chatons.

Oui, mais c’est toujours du boulot en plus à la mano…

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 :slight_smile: 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 :confused: ), 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 :

login
login
login

7 Likes

Ca a lair top votre appli ?
Mais du coup , comment cela s’intègre à NExtcloud ? via le plugin ?
Et pour l’associer à un LDAP existant ( ldaps ) ?

Merci :slight_smile:

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.