Un reproche qu’on fait régulièrement à nos services est le fait de devoir jongler entre plusieurs identifiants pour chacun des services.
Je comprends la volonté de Framasoft de ne pas proposer d’authentification unique mais pour un chaton comme le notre où les utilisateurs sont des adhérents ça aurait du sens (l’adhésion menant idéalement à la création automatique d’un compte sur tous les services).
On s’est déjà penché sur la faisabilité d’un serveur LDAP utilisé par tous nos services mais une bonne partie des logiciels utilisés ne le gère pas donc ça demanderait un gros boulot de développement.
Du coup, en attendant on envisage une solution intermédiaire : l’inscription unique.
C’est à dire que notre plateforme de gestion des adhérents permettrait de créer facilement en un clic un compte sur Mattermost, LimeSurvey, etc sans avoir à re-rentrer à chaque fois les mêmes informations (adresse e-mail, nom, prénom, etc.) ; mais ensuite les comptes vivraient leur vie séparément.
Techniquement c’est déjà beaucoup moins de boulot, puisqu’il suffirait de développer un petit programme qui appelle les API des différents services pour créer un nouveau compte.
Mais avant de se lancer là dedans, je me demandais si d’autres chatons se posent ce genre de questions ? Vous aurez peut être une meilleure idée ou alors des choses à mutualiser
Nous on utilise du ldap, c’est compatible avec beaucoup quand même. Qu’est-ce que tu as en pas compatible ?
On s’était un peu posé la question du oAuth aussi, car le ldap c’est bien mignon mais faut quand même se reconnecter à chaque fois, et ça ça crée de la friction pour pas mal de nos utilisateurs.
On réfléchit à ça, mais c’est pas une priorité
Pour ta question initiale c’est ptet pas absurde effectivement, car beaucoup plus rapide à mettre en place, mais développer des connecteurs ldap pourraient être bien plus durable ! (et notamment le soucis d’avoir des comptes séparés, c’est quand tu commences à changer de mot de passe)
Je n’ai pas revérifié récemment pour le LDAP sur nos différents outils mais le plus bloquant était Mattermost qui n’a pas de support LDAP dans la version libre.
oAuth pourrait effectivement être une solution intéressante à creuser aussi.
Nous, chez Hadoly, utilisons LDAP via FusionDirectory.
Pour l’instant nous avons des services qui se connectent à LDAP, mais nous avons aussi eu la question de ceux qui n’ont pas de connecteur.
Une solution serait d’autoriser l’accès au niveau du serveur Apache ou Nginx qui eux peuvent se connecter à LDAP.
Je n’ai pas encore eu le temps de me plonger dans LDAP autrement que par FusionDirectory. Mais dans un soucis d’automatisation j’aimerais le faire from scratch. Connaissez-vous des bons tutos, à jour ? (car OpenLDAP a changé sa gestion de configuration). Voire même des scripts ?
Les besoins sont classiques :
rassembler les utilisateurs dans des groupes
contrôler les droits d’accès par groupe
autorisation de modifier ses infos perso (mdp, mail) mais pas le reste
ajout de champs personnalisés (ex: NextcloudQuota)
…
J’ai essayé quelques heures mais j’avoue avoir un peu galéré puis être passé à autre chose.
Pour ceux qui utilisent YunoHost, les apps qui le peuvent sont automatiquement reliées au LDAP (d’ailleurs la feature suivante sera de proposer de lier ou pas au ldap justement). On utilise également la directive HTTP REMOTE_USER via ssowat ce qui permet de protéger des apps qui n’ont pas forcément de gestion de compte ou qui gèrent uniquement REMOTE_USER mais pas LDAP.
REMOTE_USER a aussi l’avantage de permettre la connexion automatique sur l’outil, ainsi on peut passer de nextcloud à roundcube sans avoir à se loguer une seconde fois.
Le corollaire, c’est que certaines apps ont du mal à se déconnecter et qu’il faut parfois patcher.
Pour ceux que la configuration de YunoHost intéressent, vous pouvez observer les packages via ce groupe github https://github.com/YunoHost-Apps/ .
Les opérations d’installation peuvent être de bonne sources de réflexion sur vos propres installations surtout si vous utilisez nginx.
Je recommande vivement d’éviter cela. One password to rule them all? Tu veux vraiment apprendre ça à tes utilisateurs? Et je rejoins:
Avec oAuth, il va falloir que les gens cliquent au moins à chaque fois!
Et ouai Mattermost est un business model open core. Je vous recommende le talk de Nextcloud sur ce sujet.
RocketChat est libre
REMOTE_USER est très tentant, mais oui, pas standard, et donc beaucoup de patch. Bon le bon point, c’est que yunohost a une communauté active Est-ce que tu sais pourquoi ces patches ne sont pas remontés upstream?
De notre côté, on en est arrivé à cette conclusion:
LDAP parrait bizarre pour l’utilisateur en terme de UX - je me logge avec le même user/pass sur toute les apps?
LDAP n’est pas très multi-tenant friendly - comment avoir un ldap pour plusieurs organisations?
oAuth est très user friendly, plein de gens utilisent Facebook connect et ses amis.
avec oAuth, les gens comprennent bien qu’ils se loggue avec un seul compte situé à tel endroit
Nextcloud est un openid connect provider
on peut configurer Nextcloud pour utiliser imap pour gérer les utilisateurs
avec Nextcloud et imap, on peut avoir plein de Nextcloud qui viennent taper sur le même imap
Du coup, c’est ce que nous sommes en train de mettre en place
Il manque juste une meilleur intégration entre Nextcloud et le backend IMAP (reset password par exemple) et la création de comptes, mais on y travaille!
Il n’est pas question d’utiliser le même mot de passe pour tout (surtout que je sais que certain.e.s de nos utilisateur.rice.s font ça actuellement pour pas avoir à jongler avec 5 mots de passes différents…).
Je parle d’inscription unique mais ça serait surtout de l’inscription en un clic au cas par cas. (Donc il faut quand même s’inscrire à chaque service, le seul gain étant de ne pas avoir à re-rentrer son nom, son e-mail, son avatar, etc.)
Donc pour ça soit on génère un mot de passe aléatoire pour chaque service, soit on en demande un.
Je suis assez d’accord avec ça, les gens ont parfois un peu de mal à comprendre à quoi ils se connectent et je pense qu’un système oAuth bien présenté peut être une bonne solution.
Une fois initialement, mais une fois que tu as lié ton compte oAuth avec tous les services, t’es plus obligé si ?
Ou alors je mélange des trucs.
Notre objectif en terme d’UX est d’obtenir la même intégration que ce que propose Google & Microsoft sur leurs suites: tu te log sur un service (n’importe lequel), et ensuite quand tu veux accéder à un autre, tu es déjà authentifié. Avec un point centrale de gestion de compte. Mais j’avoue qu’on a rien trouvé à mettre en place facilement / rapidement. Du coup pour l’instant on LDAP, et on verra plus tard. Mais effectivement si quelqu’un à une techno qui fait ça on est pour !
Si à chaque fois. Sinon, c’est une solution de SSO (single sign on) comme yunohost par exemple avec le REMOTE_USER.
Il faut juste un clique à chaque fois avec oAuth, c’est pas pire.
Perso je ne sais pas si utiliser du SSO est une bonne pratique ou pas, j’ai encore des doutes. Entre le discourt il faut privilégier des passwords différents et le portail unique joli élégant qui est le point d’entré unique l’endroit unique ou tu entres ton mdp.
Mais au niveau gestion je ne vois que des avantages dans l’utilisation d’un LDAP avec un outil comme fusiondirectory en complément(automatisation, webservice, délégation,…). De + on peut coupler l’annuaire avec un autre outil pour la gestion du SSO - par exemple LemonLDAP::NG (qui permet de faire openid connect provider, du SAML2, du CAS et co). C’est je pense une solution + modulaire que de s’appuyer sur nextcloud, mais qui demande + de taff pour intégrer le tout.
J’ai aussi pas mal de doute concernant la problématique de gestion des identités, merci aux personnes qui ont pris le temps d’expliquer comment iels font actuellement.
Merci pour le retour d’info. Pourquoi keycloak spécifiquement et pas un lemonldap::ng ? je critique pas ton choix - je souhaite juste avoir des info sur les fontctionnalitées de keycloak.
Tu utilises quoi comme backend pour stocker les info de tes utilisateurs ? Un ldap ? Si oui comment fais-tu pour le garnir ? Pour permettre aux utilisateurs d’initier un changement de password ?
branché sur un LDAP
avec une branche pour les membres de parinux (gestion par dolibar) les utilisateur.ices peuvent changer leur mdp et adresse de courriel
et une 2eme fois le même ldap sur une autre branche pour les inscriptions libre a parinux (mode registration ON)
possibilité de faire afficher des « terms of uses » que l’utilisateur.ice doit accepter pour le recueil du consentement, pour l’inscription au SSO et aussi pour l’informer lors du passage a chaque appli des données envoyé à l’application (login, email, nom, prénom…)
Je peux faire un excellent retour sur Keycloak : si vous déployez pour une structure où les membres sont identifiés, si possible sans inscription autonome (encore que c’est tout à fait faisable), et où vous mettez surtout à disposition des applications Web, c’est franchement complet, bien supporté, et ça a de belles années devant soi, donc sans hésiter.
Surtout, cela nous permet de sortir progressivement du modèle LDAP où toutes les applications voient passer le mot de passe de tout le monde à peu de choses près.
Je tenais à faire un petit retour contradictoire toutefois. Côté TeDomum, on avait jusque récemment refusé de faire du SSO et l’on pratiquait la célèbe inscription à chaque service, ce pour plusieurs raisons :
on ne souhaitait pas de package, un utilisateur devait pouvoir s’inscrire sur un ou plusieurs services de son choix, principalement parce qu’on veut inciter l’utilisateur à ne pas tout mettre chez nous, ne pas tout miser sur un acteur ;
on ne souhaitait pas si un utilisateur employait plusieurs de nos services, qu’il ait forcément le même login partout, parce qu’on a déjà constaté plusieurs cas de harcèlement où le harceleur suit la victime grâce à des identifiants reconnaissables sur plusieurs services, on souhaitait même que la victime puisse changer de pseudo à la vollée sans souci ;
on voulait limiter la diffusion des infos sur nos membres, si une appli se fait casser, on ne veut pas que l’attaquant ait accès à la liste de tous les utilisateurs de tous les services et leurs coordonnées.
Keycloak n’apporte malheureusement pas de réponse à ces questions. C’est pour cette raison qu’on a commencé à déployer un outil maison, et qu’on l’expérimente depuis six mois. On a voulu ça clairement oreinté petit hébergeur, et on fait tout dans ce sens. Entre autre un user peut avoir des comptes sur un ou plusieurs services, mais les profils sur les services sont décorrélé du compte. Il n’y a pas de package, il n’y a pas d’obligation d’utiliser le même username sur tous les services, et on peut même avoir plusieurs profils sur un même service avec son compte unique.
Mes recherches d’un logiciel pour gérer une base d’utilisateurs ont longtemps été infructueux, le choix se limitant à des produits basés sur OpenLDAP, ou en face FreeIPA/Directory389.
Keycloak est une très bonne solution, mais si l’un de vos service n’accepte que du LDAP il sera difficile de l’ajouter sans déployer l’un des deux systèmes susmentionnés.
Heureusement j’ai retrouvé un peu d’espoir récemment avec kanidm !
Je n’ai pas encore eu l’occasion de le mettre en place, mais si certains d’entre vous veulent l’essayer avant moi, je serais ravi d’avoir vos retours d’expérience.
Mattermost est un business model open core. Je vous recommende le 
