Tous les articles > Logiciel Libre > Canaille, un système léger de gestion d’identité et d’accès

Canaille, un système léger de gestion d’identité et d’accès

Depuis un certain temps l’équipe de Yaal Coop travaille sur Canaille, un logiciel de gestion d’identité et d’accès. Nous profitons de la fin de travaux financés par la fondation NLNet pour vous raconter l’histoire autour de Canaille.

Canaille

Au début étaient les annuaires

À Yaal Coop (comme presque partout ailleurs) nous utilisons une palette d’outils qui nous permettent de travailler ensemble. Emails, fichiers, carnets de contacts, gestion de projet, suivi du temps, comptabilité, intégration continue, collecte de rapports de bugs… la liste est longue. Pour des raisons de praticité (et de sécurité) on cherche généralement à connecter une telle collection d’outils à un logiciel central qui se charge de la gestion des utilisateur·ices et de leurs accès. Traditionnellement, c’est LDAP1 qui est utilisé pour cet usage, on parle alors d’annuaire.

Si un outil est connecté à un annuaire, vous n’avez pas besoin de vous y créer un compte, vous pouvez vous connecter en utilisant votre mot de passe habituel, celui que vous avez renseigné dans l’annuaire. C’est pratique pour vous puisque vous n’avez qu’un unique mot de passe à retenir (ou à oublier), on parle généralement d’inscription unique ou Single Sign On (SSO). C’est aussi pratique pour les personnes qui gèrent les comptes dans votre organisation, puisqu’elles peuvent créer et révoquer des comptes utilisateur·ices une seule fois pour tous les outils à la fois.

LDAP, c’est vieux et c’est robuste. Pour des logiciels, ce sont des qualités. Les quelques décennies d’expérience de LDAP en font une technologie éprouvée et compatible avec un énorme choix de logiciels.

Mais LDAP, c’est aussi compliqué et austère. C’est une base de donnée en arbre qui ressemble à peu d’autres choses, la documentation est éparse et absconse, les conventions sont curieuses, pleines d’acronymes angoissants, l’outillage est rare… Et puis c’est conçu pour les données qui sont lues souvent mais écrites rarement. Les modèles de données utilisables dans LDAP sont eux aussi peu évolutifs. Généralement quelques uns sont fournis d’office et permettent de manipuler des attributs de base sur des utilisateur·ices et des groupes. Et si on veut que son système puisse gérer d’autres attributs comme les couleurs préférées, alors il faut écrire ses propres modèles de données, et on a intérêt à être sûr de soi puisqu’aucun mécanisme de mise à jour des schémas ou de migration des données n’est prévu2. Si on souhaite ensuite partager ces modèles de données, alors il est conseillé de s’enregistrer à l’IANA3, et de fournir une référence en ligne de ses schémas. Quand on se plonge dans l’univers de LDAP, on a l’impression qu’une fois mises en place, les installations ne bougent pas pendant des années ; et donc les personnes qui ont la connaissance fuient l’austérité de cette technologie sans avoir à s’y ré-intéresser (puisque ça fonctionne), et sans trop documenter leurs aventures. J’exagère à peine, si on compare4 le nombre de questions sur stackoverflow, pour ldap on en dénombre environ 1000 tandis que postgresql ou mongodb en comptent environ 14 000 et mysql 45 000.

Puis vint l’authentification unique

Lors de temps de bénévolat à Supercoop5, nous avons notamment travaillé à installer, comme pour chez nous, plusieurs outils numériques de collaboration. Évidemment tous les outils étaient branchés sur un annuaire LDAP. Nous nous sommes rendus compte que l’équipe dite de gestion des membres, passait un certain temps à traiter des demandes de réinitialisation de mot de passe, à aider des personnes qui échouaient à utiliser les outils dès les premières étapes de connexion. Ce constat nous a donc poussé à chercher des outils (libres, évidemment) d’authentification unique et de gestion d’utilisateur·ices, en complément ou remplacement de l’annuaire. Ce que l’authentification unique ou Single Login Identification (SLI) apporte au SSO fourni par LDAP, c’est que les utilisateur·ices peuvent naviguer entre les outils sans avoir à s’identifier à nouveau. On peut passer de l’interface mail à son calendrier en ligne sans repasser par l’écran d’identification, tandis qu’avec un simple annuaire, il aurait été nécessaire d’entrer son mot de passe une fois pour chaque outil. Pour un public non technophile, c’est l’opportunité de se passer de quelques écrans techniques, et limiter les sources d’erreur et de frustration.

Actuellement les protocoles de prédilection pour faire du SLI sont OAuth2 et OpenID Connect (OIDC)6. On note qu’il existe d’autres standards, plus historiques ou bien plus orientés vers les grosses organisations, tels SAML ou CAS. Les normes OAuth2 et OIDC sont modernes mais bénéficient d’une dizaine d’années de retours d’expérience. Les outils et les documentations sont nombreuses, la communauté est active, et les standards évoluent en ce moment même grâce au groupe de travail oauth de l’IETF7. Mais là encore tout n’est pas rose et OIDC vient avec son lot de difficultés.

Tout d’abord, OAuth2 et OIDC c’est environ 30 standards complémentaires, dont certains contredisent et apportent des corrections sur des standards antérieurs. Tous ne sont pas pertinents dans l’usage que nous visons, mais ne serait-ce que simplement comprendre le fonctionnement de ceux qui nous intéressent demande déjà du temps et de la réflexion. Les implémentations d’OIDC — par les logiciels de gestions d’utilisateur·ices, ou par les outils qui s’y branchent — sont généralement partielles, et parfois bugguées. Pour ne rien arranger, les gros acteurs de l’industrie prennent délibérément des libertés avec les standards et forcent le développement de spécificités pour être compatibles avec leurs logiciels.8

Mais revenons à nos moutons. Pour Supercoop nous souhaitions trouver un outil qui soit d’une grande simplicité à plusieurs points de vue :

  • pour les utilisateur·ices : les coopérateur·ices du magasin. L’utilisation doit se faire sans aucune connaissance technique préalable, et sans assistance ;
  • pour l’équipe de gestion des membres du magasin. Nous voulions un outil simple à prendre en main. Un apprentissage de l’outil est envisageable mais non souhaitable. En effet le magasin fonctionnant grâce à la participation de bénévoles, il y a un enjeu à ce que le temps passé soit le moins rébarbatif possible, afin de ne décourager personne.
  • enfin pour l’équipe informatique, il y a là aussi un enjeu de simplicité. Si les outils déployés pour le magasin requièrent trop de connaissances, nous aurons des problèmes pour trouver des gens compétents pour nous aider. Et la nature de la participation du magasin fait que les coopérateur·ices contribuent ponctuellement, tournent souvent, et n’ont pas nécessairement le temps d’apprendre toute la pile technique mise en œuvre. Idéalement, l’équipe informatique devrait pouvoir administrer l’outil que nous recherchons avec une connaissance superficielle des protocoles concernés. Et vues les descriptions que j’ai faites de LDAP et OIDC, vous commencez à cerner une partie du problème.

Notre recherche nous a montré qu’il existait une quinzaine d’outils pouvant répondre aux besoins que nous avons identifiés. Pour autant, aucun outil ne nous semblait cocher toutes les cases. En fait, par leur nature, les outils de gestion d’identité et d’autorisations ou Identity and Authorization Management (IAM) sont destinés à de grosses organisations, qui peuvent donc s’offrir les services de personnes qualifiées pour s’en occuper. Ce sont donc des logiciels lourds mais puissants, supportant beaucoup de protocoles qui ne nous concernent pas, requiérant une certaine technicité pour l’installation, la maintenance ou la gestion. Motivés par notre curiosité nous avons fini par bricoler quelque chose dans notre coin.

Canaille

Quelques temps après, notre prototype a grossi et a donné Canaille.

Les fonctionnalités

Canaille est un logiciel qui permet de gérer des utilisateur·ices et des groupes d’utilisateur·ices, de créer, modifier et administrer des comptes, de réinitialiser des mots de passes perdus, d’inviter des nouveaux utilisateur·ices. En plus de ça, Canaille implémente OIDC et fournit donc une authentification unique aux utilisateur·ices vers d’autres outils. Son interface est personnalisable et … c'est tout. Nous tâchons de garder le périmètre fonctionnel de Canaille assez restreint pour qu'il reste simple.

Canaille peut être utilisé pour :

  • apporter une interface web épurée de gestion des comptes utilisateur·ices au dessus d’un annuaire LDAP. L’outillage autour de LDAP étant comme on l’a dit plutôt épars, Canaille peut être utilisé pour modifier facilement un profil utilisateur·ice ou réinitialiser un mot de passe perdu.
  • amener du SLI sur un annuaire LDAP. Si vous avez historiquement un annuaire LDAP et que vous voulez moderniser votre pile logicielle avec une couche d’authentification unique, Canaille peut s’intégrer discrètement au-dessus de votre installation existante sans rien modifier, et vous laisser le temps de prévoir – ou pas – une migration.
  • développer des applications utilisant OIDC. Si, comme nous, vous faites du développement logiciel et travaillez régulièrement sur des applications nécessitant une connexion OIDC, alors vous pouvez utiliser Canaille dans votre environnement de développement. Canaille étant très léger, c'est désormais pour nous la solution de choix comme IAM pour travailler sur nos applications.
  • tester des applications utilisant OIDC. Nous utilisons aussi Canaille dans des suites de tests unitaires python, grâce à pytest-iam. Ce greffon de pytest embarque Canaille, le prépare et l’instancie pour que vos suites de tests puissent effectuer une réelle connexion OIDC.

Les choix techniques

Canaille est un logiciel écrit en python, avec flask pour le côté serveur et fomantic-ui et htmx pour la partie client utilisateur·ice. Nous apprécions la simplicité de python et celle de flask et croyons sincèrement que ce sont autant de freins en moins à la participation d’éventuels contributeur·ices. Nous avons été sidérés par notre découverte récente de HTMX, qui en deux mots nous permet de créer des pages web dynamiques sans plus écrire de Javascript. Un langage en moins dans un projet c'est autant de complexité en moins.

Sous le capot, Canaille peut se brancher au choix à un annuaire LDAP ou à une base de données SQL.

Les techniques de développement

Nous utilisons Canaille en production, à Supercoop donc où il est utilisé pour gérer environ 1800 membres, mais aussi chez nous à Yaal Coop et au sein de notre offre mutualisée de services Nubla, et sur des instances dédiées Nubla Pro. Cette large base d’utilisateur·ices nous permet de récolter des retours d’expérience, et nous améliorons le logiciel au fur et à mesure des besoins.

Canaille suit le principe du développement dirigé par les tests, ou Test Driven Development (TDD), dans la mesure du possible. La couverture du code est de 100% (branches comprises), et c’est un pré-requis pour toute contribution. En plus d’avoir confiance dans nos tests, cela nous a permis à plusieurs reprises de simplement supprimer du code qui n’était plus utilisé, et simplifier d’autant le projet. On débusque plus facilement les bugs quand il y a moins de code.

Canaille utilise tous les analyseurs et formatteurs de code source modernes, au sein de pre-commit, et les test unitaires sont joués sur toutes les versions de Python officiellement supportées.

Enfin la traduction de l’interface de Canaille se fait de manière communautaire sur weblate.

Contributions

Comme la plupart des logiciels modernes, Canaille réutilise des bibliothèques logicielles existantes pour que nous n’ayions pas à ré-inventer ce que d’autres ont déjà fait.

Lorsque nous rencontrons des erreurs dans ces bibliothèques, nous suivons une stratégie qui consiste à implémenter les corrections à la fois dans Canaille et dans les logiciels. D’une part nous amenons donc les corrections dans Canaille, de manière temporaire et efficace. Mais tout ce code que nous écrivons nous-même est un fardeau de maintenance à venir, nous tâchons donc en parallèle de proposer des solutions mieux conçues aux mainteneur·euses desdites bibliothèques, en discutant avec eux en amont. C'est pour nous la garantie que les briques logicielles sur lesquelles nous nous appuyons sont pérennes, et c’est un moyen de contribuer à cet écosystème nécessaire qu’est celui du logiciel libre.

Par ailleurs lorsque nous souhaitons des fonctionnalités supplémentaires dans ces bibliothèques, nous expliquons nos motivations aux mainteneur·euses et parfois proposons des implémentations. Nous avons par exemple développé le support des spécifications OIDC RFC7591 et RFC9068 dans authlib, une brique utilisée pour la partie OIDC de Canaille.

Le résultat de ces efforts est visible dans nos articles trimestriels de contributions à des logiciels libres.

Le hasard des contributions nous a amené à partager la maintenance de certaines des bibliothèques que nous utilisons, comme wtforms qui permet de gérer les formulaires dans Canaille, ou encore nextcloud-oidc-login et OpenIDConnect-PHP qui permettent à nextcloud (le gestionnaire de fichiers proposé par Nubla) de se connecter à Canaille.

Nous sponsorisons aussi modestement tous les mois les mainteneur·ices de fomantic-ui et authlib.

L’aide de la fondation NLNet

Canaille a été développé pour répondre aux besoins spécifiques que nous avons rencontrés : à l’origine Canaille s’interfaçait donc seulement avec des annuaires LDAP. L’écosystème évoluant, nous nous sommes aperçus que de plus en plus de logiciels étaient capables de communiquer avec OIDC en plus de LDAP. In fine, si plus aucun des logiciels que nous utilisons ne dépend directement de LDAP, alors nous pouvons envisager un outil de remplacement avec lequel nous nous sentons plus à l’aise. Pour aller dans cette direction, nous avons sollicité fin 2022 l’aide de 7 000€ au fond NGI Zero Entrust de la fondation NLNet pour financer le support de travaux dans Canaille :

Canaille

Ces développements ont été achevés fin novembre 2023, et ont été la source de nombreux réusinages, de nombreuses corrections de bogues, et plus généralement d’une meilleure conception et d’une meilleure fiabilité de Canaille. Nous sommes particulièrement reconnaissant·es à la fondation NLNet de nous avoir permis de travailler sur notre outil, et de nous aider à contribuer à notre échelle à l’écosystème du logiciel libre.

Et la suite ?

Passer en version bêta

Nous avons depuis le début gardé Canaille en version alpha, nous sommes à l’heure actuelle à la version 0.0.35. Nous indiquions que le logiciel était impropre aux environnements de production. C’était pour nous un moyen de pouvoir expérimenter dans notre coin sans avoir à se soucier de rétrocompatibilité. Nous souhaitons sévir une dernière fois en remettant à plat la manière de configurer Canaille avant de passer Canaille en bêta, et lever les mises en garde d’usage.

Nous regroupons les tickets pour le passage en version bêta de Canaille dans ce jalon.

Passer en version stable

Les travaux que nous immaginons réaliser pour passer d’une version bêta à une version finale sont principalement des efforts de documentation, d’installation et de prise en main de Canaille. L’objectif est pour nous de rendre Canaille facile d’accès, afin de créer de l’usage et collecter des retours utilisateurs.

Nous regroupons les tickets pour le passage en version stable de Canaille dans ce jalon.

Et au-delà…

Pour l’avenir nous souhaitons travailler sur le provisionnement, en implémentant la norme SCIM. Ce travail permettra de découpler l’authentification des utilisateur·ices et la création des comptes utilisateur·ices. En effet aujourd’hui dans les outils externes que nous avons branchés à Canaille, les comptes des utilisateur·ices sont créés à la première connexion. Cela peut s’avérer problématique dans certaines situations : par exemple si l’on veut partager des fichiers dans Nextcloud avec un utilisateur·ice qui ne s’est encore jamais connecté. SCIM permet aussi de supprimer des comptes utilisateur·ices sur ces outils externes, tâche qui doit être réalisée plus ou moins manuellement à l’heure actuelle.

Parmi les chantiers à venir, nous voyons aussi le travail sur la déconnexion unique, ou Single Log-Out (SLO). C’est un développement qui devra être réalisé en premier lieu dans authlib, et qui permettra aux utilisateur·ices de se déconnecter de tous les outils en une seule action. C’est une fonctionnalité qui apportera de la sécurité et du confort d’utilisation.

Enfin, nous aimerions travailler sur une gestion avancée des groupes d’utilisateur·ices et des droits, ainsi que sur des mécanismes d’authentification multi-facteurs.

Si tout cela vous intéresse, vous pouvez tester Canaille immédiatement sur notre interface de demo. Canaille est évidemment ouvert aux contributions, alors si vous souhaitez nous aider dans tout ça, la porte est ouverte !

  1. enfin, un logiciel qui implémente LDAP, ici je parle indifféremment du protocole ou de ses implémentations ↩︎
  2. du moins avec OpenLDAP ↩︎
  3. ce que nous avons fait, notre numéro à l’IANA est le 56207 ↩︎
  4. d’accord, la comparaison est fallacieuse puisque ces différentes bases de données ne répondent pas aux mêmes besoins, mais l’ordre de grandeur est révélateur de l’intérêt autour de ces technologies ↩︎
  5. le supermarché coopératif de l’agglomération bordelaise ↩︎
  6. par abus de langage, je dirai simplement OIDC ↩︎
  7. l’« Internet Engineering Task Force » un organsime étasunien de développement et de promulgation de standards ↩︎
  8. Ils peuvent aussi êtres moteurs de nouvelles améliorations, comme RFC7628 ou RFC9068 qui furent des usages avant d’être des standards. ↩︎