Configuration d'un système d'authentification pour Ikiwiki 🔗
Introduction¶
Ikiwiki permet d'éditer des pages en ligne. Jusqu'à présent, j'utilisais uniquement Git pour commiter des articles sur ma plate-forme Ikiwiki. C'est un moyen assez efficace pour publier des articles car j'utilise mon éditeur de texte favori (Emacs) pour le faire et ça ne pose aucun problème.
Néanmoins, parfois, on a besoin d'effectuer juste une petite correction et le faire dans un navigateur Web reste sans doute le moyen le plus efficace. Mais qui dit édition en ligne, dit sécurité ! Il ne faut pas en effet que n'importe qui puisse réaliser ces modifications sans contrôle.
Mon cas d'utilisation est assez simple: il n'y a qu'un seul utilisateur qui publie sur la plate-forme. Je n'ai donc pas besoin de mettre en place un système complexe basé sur une base de données. De plus, j'aimerais bien pouvoir réutiliser une des méthodes d'authentification dont je me sers fréquemment.
Ces besoins impliquent d'utiliser un plugin particulier d'Ikiwiki qui se nomme httpauth. Ce dernier permet de déléguer le mécanisme d'authentification au serveur Web. En cas d'authentification réussie, ce dernier passe la main au CGI d'Ikiwiki avec les bons paramètres.
Cet article tente d'illustrer la configuration de ce plugin dans Ikiwiki ainsi que la mise en place du mécanisme d'authentification de manière à disposer d'une édition en ligne sécurisée.
Installation des paquets nécessaires à l'authentification¶
Pour faire fonctionner le plugin httpauth
, il est nécessaire de
disposer des bons modules Perl. En effet, le CGI d'Ikiwiki ne permet
pas grand-chose sans les bons paquets. Si vous tentez d'utiliser le
plugin httpauth
sans ces modules, le CGI retournera une erreur.
# aptitude install libcgi-session-perl libcgi-formbuilder-perl
Avec ces modules, le CGI d'Ikiwiki est capable de générer des formulaires web ainsi que de gérer des sessions. C'est tout ce dont nous avons besoin à ce niveau.
Configuration d'Ikiwiki¶
si vous consultez la documentation d'Ikiwiki sur
l'authentification, vous
pourrez constater qu'il y a plusieurs méthodes autres que
httpauth
. Par défaut, Ikiwiki utilise
passwordauth. Ce dernier
créé une base de données utilisateur (dans le répertoire
.ikiwiki/userdb
) qui gère les accès. Par défaut, cette base est
ouverte, c'est à dire qu'on peut s'y enregistrer simplement en
remplissant un formulaire. En conclusion, si vous laissez Ikiwiki sans
modifier sa configuration, n'importe qui pourra créer et modifier des
articles en créant un compte bidon. Voilà pourquoi il faut enchaîner
toute de suite avec la configuration du plugin httpauth
.
Vous devez modifier votre fichier de configuration Ikiwiki (fichier
.setup
). Voici ce que j'ai fait au mien:
…
# plugins to add to the default configuration
add_plugins => [qw{goodstuff format highlight toggle img rawhtml favicon sidebar meta calendar search editpage httpauth}],
# plugins to disable
disable_plugins => [qw{passwordauth openid anonok}],
…
# httpauth plugin
# url to redirect to when authentication is needede
cgiauthurl => 'https://example.org/auth/ikiwiki.cgi',
…
J'ai tout simplement ajouté le plugin editpage pour permettre l'édition de pages ainsi que le plugin httpauth pour la gestion de l'authentification.
Ensuite, j'ai préventivement désactivé tous les autres plugins liés à l'authentification (passwordauth, openid et anonok).
Enfin, j'ai renseigné une variable nommée cgiauthurl
. Cette dernière
permet au CGI d'Ikiwiki d'être accédé depuis une autre URL
lorsqu'aucune session valide n'a été repérée. C'est ce mécanisme qui
va nous permettre de gérer l'authentification. Il suffira de
déclencher une authentification lorsqu'un utilisateur désire accéder à
https://example.org/auth/ et le tour sera joué. Remarquez que cette
page est accédée via TLS (HTTPS) ce qui n'est pas un hasard.
Vous aurez sans doute besoin de créer le répertoire défini par
cgiauthurl
. Dans mon cas, j'ai juste créé le répertoire
/var/www/auth
avec les bons droits (ceux pour www-data) et réalisé
un lien symbolique de /var/www/ikiwiki
vers
/var/www/auth/ikiwiki.cgi
:
# mkdir /var/www/auth
# chown www-data:www-data /var/www/auth
# ln -s /var/www/ikiwiki.cgi /var/www/auth/ikiwiki.cgi
Il faudra bien sûr adapter ces chemins à votre installation d'Ikiwiki.
Pour prendre en compte ce changement de configuration vous aurez besoin de regénérer le CGI d'Ikiwiki. Cette opération est déclenchée lorsque vous reconstruisez l'ensemble du site:
$ ikiwiki --setup ikiwiki.setup
Configuration Apache¶
Maintenant que nous avons configuré Ikiwiki, il reste à s'occuper
d'Apache. En effet, c'est bien le serveur HTTP qui va réaliser une
authentification de type Basic et passer la main au CGI d'Ikiwiki si
l'authentification s'est correctement déroulée. Le serveur Web envoie
le nom de l'utilisateur authentifié au CGI via une variable
d'environnement, nommée REMOTE_USER
.
Puisque l'authentification se fera en mode Basic, une connexion
chiffrée est indispensable ! C'est à cet effet que nous avons
délibérément configuré la variable Ikiwiki cgiauthurl
en
https. Ainsi, lorsqu'un utilisateur tente d'éditer une page en mode
HTTP standard, il est automatiquement redirigé vers la partie HTTPS du
site et aucun mot de passe ne transitera en clair sur le réseau.
Il faut donc éditer cette partie au niveau de la configuration d'Apache pour déclencher une authentification. Je ne vais pas rentrer dans les détails car votre configuration peut être très différente de la mienne. Dans mon cas, j'ai juste défini un nouvel emplacement dans la configuration du VirtualHost dédié à HTTPS:
# Ikiwiki authentication
<Directory /var/www/auth/>
Options -Indexes FollowSymLinks MultiViews +ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthType Basic
AuthName "Ikiwiki authentication"
AuthUserFile /etc/apache2/my_userdb
Require valid-user
</Directory>
Attention, le CGI d'Ikiwiki utilise la variable d'environnement
REMOTE_USER
retournée par Apache pour déterminer le nom de
l'utilisateur authentifié. Si vous avez défini cette variable (avec un
SetEnv
par exemple) dans votre configuration Apache et même si cette
valeur est nulle, Ikiwiki l'utilisera et considérera que l'utilisateur
est authentifié. Dans mon cas, j'avais un comportement assez
particulier: Ikiwiki ne me demandait jamais de m'authentifier et le
nom de l'utilisateur pour la session était vide. J'avais tout
simplement initialisé la variable d'environnement REMOTE_USER
par
défaut car j'avais mis en place sur mon serveur un accès Git par HTTP
(git-http-backend). Ce
dernier définissait la variable de la manière suivante:
SetEnv REMOTE_USER=$REDIRECT_REMOTE_USER
Lorsque j'accède à mes dépôts Git via HTTP(S), le client Git remonte
la variable REDIRECT_REMOTE_USER
. Mais lorsqu'on n'utilise pas Git
(ce qui est le cas lorsqu'on édite une page avec le CGI d'Ikiwiki), la
variable d'environnement REDIRECT_REMOTE_USER
est vide. Cette
configuration Apache créé la variable REMOTE_USER
, peu importe le
cas. Cette définition est trop générale (et risquée).
À la place, il faut définir autrement cette variable dans la configuration Apache:
SetEnvIf Request_URI "^/git/" REMOTE_USER=$REDIRECT_REMOTE_USER
Dans ce cas, la variable REMOTE_USER
n'est définie que pour les URLs
qui commencent par /git/
(ce qui n'est pas le cas lorsqu'on édite
une page avec le CGI d'Ikiwiki). Ne pas redéfinir cette variable en
mode conditionnel conduit à un vrai trou de sécurité ! Alors faîtes
bien attention à votre configuration Apache…
Conclusion¶
Dans cet article, on voit que la mise en place d'un système d'authentification est assez accessible. Il y a juste quelques modules Perl à installer ainsi qu'un minimum de configuration d'Ikiwiki et d'Apache. Je ne peux que vous recommander d'effectuer quelques tests en pré-production avant de valider la configuration car l'enjeu est important: si vous n'avez pas assez sécurisé cette partie, n'importe quel attaquant pourra vous pourrir vos articles (ou faire du DDOS).
Maintenant, je peux faire de l'édition en ligne de manière sécurisée. Cet article a d'ailleurs été complètement rédigé en ligne !
Note de l'auteur du 12/04/2020: Avec le temps, je n'ai finalement jamais utilisé cette fonction d'édition en ligne: une fois sur deux je paumais mon mot de passe tellement je ne créais plus de contenu sur cette plate-forme. Aujourd'hui, je passe exclusivement par un éditeur de texte et un commit. D'une manière générale, avec l'expérience, on ne peut pas combiner rédaction sérieuse et publication rapide. Il faut toujours beaucoup de temps pour écrire quelque-chose de valable, encore plus de temps pour en faire la relecture, la reformulation, etc. Alors, publier en ligne rapidement ! On ne le fait jamais au final. Sans compter l'aspect sécurité et maintenance du truc. Encore une fausse bonne idée !