Une problématique à laquelle j'ai été confronté pour l'April est l'interfaçage entre l'outil de gestion des adhérents et l'interface de gestion de listes de discussion sympa (wws) Ce dernier permet aux adhérents de gérer leurs abonnements aux listes de discussion sympa utilisé par l'April.

La problématique est la multiplication des mots de passe, ce qui introduit tous les soucis de gestion qu'on puisse imaginer.

La solution retenue pour partager l'authentification consiste à forger l'authentification de wws pour lui faire croire que le membre est déjà authentifié. Si on regarde le code source ainsi que le manuel de sympa, on se rend compte que wws utilise un cookie pour la gestion de session. Ce cookie, appelé sympauser contient l'adresse email de l'utilisateur authentifié, ainsi qu'une somme de contrôle MD5 utilisant un secret contenu dans la configuration de sympa.

Il ne reste donc à une application qui veut faire du SSO sur wws qu'à forger ce cookie. C'est donc ce que fait gDTC à chaque authentification. Ainsi, lorsque l'utilisateur s'authentifie, on lit le secret de wws (qui est placé dans /etc/sympa/cookie sous Debian GNU/Linux, ne pas oublier de corriger les permissions pour permettre à gDTC de pouvoir le lire).

La partie délicate est que le client autorise le cookie en question sur les deux applications. Il est donc nécessaire qu'elles soient placées sur le même serveur web ou à défaut dans le même domaine. gDTC positionne d'ailleurs le cookie de sympa pour tout le domaine configuré.