TeDomum

... sans en avoir trop honte !

Ces derniers mois l'idée a mûri et il est grand temps que ce blog s'en fasse le relais puisque nous expérimenterons dès ce week-end sur de premiers services en production : Hiboo, notre nouvelle usine à gaz.

Si Hiboo est tout ce qui vous intéresse plutôt que l'historique, vous pouvez avancer directement à la section « Que s'apeleriá Hiboo »

Un problème avec l'authentification

L'authentification d'utilisateurs sur un service distant n'est pas un sujet neuf, et une successions de philosophies, chacune accompagnée de sa pile de protocoles et d'outils, fournit aujourd'hui un beau panel de possibles. Résumons chronologiquement.

Au commencement était la base d'utilisateurs, locale sur chaque machine. Cette base, que certains ont matérialisée dans un /etc/passwd, d'autres dans les tables SQL de leur application Web, détenait la vérité sur les utilisateurs, leur mot de passe et leur profil.

Le problème est rapidement devenu évident : chaque administrateur connaissait les mots de passe de tous ses utilisateurs. Pour peu – suivez mon regard – que les utilisateurs ré-employassent leur mot de passe sur plusieurs systèmes, chaque administrateur détenait en réalité les clés de leur vie numérique.

Bien entendu et même si les paragraphes sont rédigés au passé (y compris du subjonctif !) : cette époque n'est pas révolue. Quelques mécanismes ont été mis en place pour limiter les dégâts lorque les informations fuitaient : utilisation de hachage cryptographique à l'état de l'art pour rendre plus difficile la récupération du mot de passe réel de l'utilisateur par exemple. Ceci n'empêche que la majorité des applications emploie toujours ce modèle en 2019 ; et que la majorité des administrateurs ont, sur chaque service, une copie de nos mots de passe.

Plus tard on a suggéré que centraliser ce stockage le rendrait plus difficilement accessible à un attaquant, mais aussi plus facilement maintenable. L'IT d'entreprise a ainsi adoubé LDAP et ses concurrents, pour que chaque application interroge le stockage central des authentifiants. Malheureusement dans ce modèle, les applications connaissent toujours le mot de passe de chaque utilisateur qui se connecte.

Les années 80, 90, enfin les années 2000 et plus récentes ont vu fleurir la notion de tiers authentifiant. D'abord Kerberos, puis SAML, SAML2, OAuth, enfin OAuth2 et son cousin OpenID Connect offrent la possibilité de centraliser l'authentification sans que l'application ait accès au mot de passe. Comment ? grâce à la magie de la cryptographie essentiellement ; nous vous renvoyons à la documentation de chacun de ces standards pour les détails plus ou moins gores.

TeDomum dans tout ça

Où en est-on chez TeDomum aujourd'hui ? Au triste niveau de la base d'authentifiants gérée par chaque service. C'est un choix que nous avons fait il y a plusieurs années selon le raisonnement suivant.

La plupart des applications que l'on déployait à l'époque supportait soit LDAP, soit un stockage local. L'alternative LDAP posait un risque supplémentaire : non seulement les applications continueraient d'accéder au mot de passe utilisateur, mais en prime l'utilisateur n'aurait plus le choix que d'utiliser le même pour tous nos services. On n'aurait rien apporté à un utilisateur peu consciencieux, et on aurait pénalisé les internautes motivés qui configuraient déjà un mot de passe différent par application. Nous avions donc opté pour le moindre mal : ne rien changer.

Notre objectif dorénavant : fournir enfin une authentification unique pour nos services, mais sans révéler le mot de passe à chaque application, et en proposant des mécanismes modernes, multi-facteurs, adaptés.

Que s'apeleriá Hiboo

Le bon sens voulut que nous options pour une solution du marché (Gluu et Keycloak ne sont que deux exemples de qualité dans un écosystème assez bien fourni), mais la lourdeur et le manque de souplesse de ces implémentations nous ont freinés. Aussi, contre toute raison, et comme nous l'avions fait en 2014 en débutant le développement de Mailu, nous nous sommes lancés from scratch.

L'objectif d'authentification centralisée a guidé la réflexion, mais il est loin d'être le seul besoin : plusieurs se sont par exemple présentés en réfléchissant aux manières d'implémenter SAML2 et OpenID Connect, les protocoles retenus pour migrer notre authentification.

C'est ainsi qu'est né le projet Hiboo, où nous souhaitons développer notre capacité à gérer sur le plan technique la communauté d'utilisateurs et de services de l'association de façon unifiée et sécurisée.

Métadonnées des utilisateurs

La gestion des métadonnées nous pose conceptuellement problème dans les solutions standard d'authentification : en général, le fournisseur d'identité détient le profil de l'utilisateur et autorise les applications à y accéder. Hors, nous ne souhaitons pas que chaque application stocke à sa guise des copies des informations privées de nos utilisateurs, à commencer par leur adresse e-mail.

En attaquant le problème par l'e-mail (nous avons bien d'autres fronts à couvrir), nous proposons une solution où l'utilisateur peut recevoir des notifications sans communiquer ses coordonnées directement à l'application.

Hiboo pseudonymise ainsi l'adresse de contact et joue le rôle de relai. A terme, nous devrions même pouvoir relayer ces messages, après filtrage par l'utilisateur, sur une messagerie au choix. Qui n'a jamais rêvé de recevoir ses notifications applicatives sur Matrix ?

Gestion multi-profils

Au sein de l'équipe TeDomum, nous avons chacun plusieurs profils sur nos services, pour tester, pour administrer, pour notre usage personnel quotidien. Devoir gérer les mots de passe de tous ces profils est coûteux et sujet à erreurs. Nous souhaitions faciliter ces manipulations.

Aussi, nous avons été témoins de quelques cas de harcèlement où malheureusement, malgré les mesures prises pour désarmer l'agresseur et les moyens à disposition pour bloquer ou ignorer ses messages, la victime n'avait plus d'autre choix que de créer de nouveaux comptes pour changer de visage numérique et y échapper. Il nous paraissait primordial d'accompagner ces changements, voire de les rendre faciles et autonomes.

Ainsi, Hiboo décorrèle le compte utilisé pour s'authentifier des profils exposés aux applications. Je peux m'authentifier sur mon unique compte « john » et me connecter à Mastodon en tant que « alice » le matin et « bob » l'après-midi, de même que je peux me connecter à Pixelfed en tant que « john » ou « charlie » quand je le souhaite.

L'adresse e-mail fournie étant la seule métadonnée et comme elle est pseudonymisée, l'application ne peut pas relier mes différents profils entre eux (nos applications n'accèdent par ailleurs pas à l'adresse IP source, même s'il nous reste un peu de travail pour masquer le user agent). Mieux : nous avons prévu que le modérateur lui-même ne puisse pas nativement lier ces profils entre eux (nous réfléchissons aux outils pour aider la modération sans compromettre la vie privée des utilisateurs).

Chaque application a son quota de profils pour éviter les débordements, pour certaines les profils supplémentaires sont soumis à validation du modérateur, pour d'autres les profils ne peuvent être créés que par un administrateur, etc.

Gestion de la migration

La part la plus difficile de ce nouveau type de composant reste classiquement la migration. Chaque utilisateur de nos services a aujourd'hui son compte sur une, deux, voire plus d'applications que nous hébergeons. Quelque fois ces comptes ont le même nom, parfois ce n'est pas le cas, voire souvent un même nom employé sur une application est en réalité détenu par un autre utilisateur sur une autre application. Comment gérer alors la reprise des milliers de comptes existant sans cafouillage et des mois de préparation ?

C'est là encore que décorréler comptes d'authentification et profils applicatifs nous a rendu service. Chacun est libre de créer le compte d'authentification qu'il souhaite sur Hiboo. Seules quelques rares applications (essentiellement les services d'administration internes à TeDomum) utilisent ce nom de compte pour authentifier l'utilisateur.

Puis, nous importons par application la liste des profils déjà réservés car appartenant historiquement à un utilisateur de l'application. Ces profils sont « récupérables » dans Hiboo en fournissant le mot de passe du compte original ; ils sont alors importés dans le compte Hiboo et utilisables directement (dans la limite du nombre de profils autorisés).

Où en sommes-nous ?

Hiboo n'est plus une chimère, nous le testons depuis quelques semaines et le code est public sur notre forge : https://forge.tedomum.net/acides/hiboo.

Il s'agit d'un développement Python Flask et SQLAlchemy pour le stockage. La gestion des comptes et profils est développée sur mesure, tandis que OpenID Connect et SAML2 sont respectivement implémentés par Authlib et pySAML2, deux excellentes bibliothèques.

A l'heure où nous publions cet article, nous importons les comptes de notre instance Mastodon dans notre serveur Hiboo de production, afin d'ouvrir dans les heures ou jours qui viennent le service pour l'authentification sur Mastodon. Si tout se déroule sans accroc, nous poursuivrons avec l'ensemble des applications supportant SAML2 ou OpenID Connect (soit l'essentiel de nos services).

Perspectives pour Hiboo

Nous ne plaisantons pas en décrivant Hiboo comme notre nouvelle usine à gaz : il reste une montagne de fonctionnalités à ajouter pour en faire notre premier outil de gestion technique de communauté. Mais nous prêterons attention à ce qu'il demeure simple de conception, maintenable et auditable.

D'abord, l'anti-spam. Nous avons travaillé ces derniers mois à la conception de CAPTCHA pour limiter le spam sur nos services. Nous avons espoir que le déport d'authentification calme les robots mais il n'arrêtera pas les spammeurs motivés. Pour cela nous planifions d'intégrer rapidement un système de CAPTCHA modulaire, utilisable par Hiboo lui-même mais également par les applications tierces. Les premiers modules reprendront des CAPTCHA sur étagère (dont le décrié reCAPATCHA, en limitant au maximum le tracking Google associé).

Ensuite, l'authentification forte : nous projetons d'intégrer des bibliothèques d'authentification multi-facteurs, avec en premier lieu du TOTP. Plus généralement, nous souhaitons un modèle d'authentification générique pour Hiboo, où chacun peut choisir son mode d'accès : mot-de-passe, certificat client, voire qui-sait un compte sur un service tiers ? (on pense bien entendu à Facebook et Google, mais nous imaginons plutôt une fédération d'identité « à la » Fediverse, où chacun pourrait employer son compte d'une autre instance Hiboo, comme le suggérait à sa conception le standard OpenID).

Pour terminer, nous envisageons d'y intégrer nos outils de modération assez largement : gestion des comptes, blocage temporaire, suivi des rappels à l'odre, prise en compte des requêtes externes (administratives et judiciaires principalement), blocage rapide d'URL, etc.

Une chose est certaine : nous ne manquons pas de travail. Aujourd'hui une poignée à contribuer, nous espérons que les concepts proposés dans Hiboo séduiront d'autres hébergeurs associatifs. Ce sont les retours de la communauté, et idéalement les contributions à la conception et au code, qui décideront du succès de Hiboo.