Ajouter la 2FA à une application web héritée sans toucher à son code

Toute entreprise en a une : l’application web interne qui fait tourner la moitié de l’activité, dont l’éditeur a disparu depuis longtemps ou dont plus personne n’ose toucher au code source, et que l’auditeur veut désormais placer derrière une authentification multifacteur.

Nul besoin de la modifier. Vous n’avez même pas à savoir dans quel langage elle est écrite. L’astuce consiste à traiter l’application comme une boîte noire et à placer l’authentification en amont : un reverse proxy qui parle SAML, adossé au service SSO de Notakey, de sorte que chaque utilisateur doive approuver sa connexion d’un toucher sur son téléphone avant qu’une seule requête n’atteigne l’application.

Comment ça fonctionne

Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
                 │
                 └──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone

1. Le navigateur demande une URL protégée. Le proxy ne trouve aucune session SAML et redirige vers le fournisseur d’identité : le service SSO livré avec l’appliance Notakey.
2. L’utilisateur saisit son nom d’utilisateur ; le serveur d’authentification envoie une demande d’approbation en notification push sur son téléphone.
3. Après approbation, le navigateur revient avec une assertion SAML signée. Le proxy vérifie la signature et ne laisse passer les requêtes vers l’application qu’à cette condition.

L’application elle-même ne change jamais. Si elle possède son propre écran de connexion, celui-ci reste inchangé : on ajoute un poste de contrôle en amont, sans remplacer ce qui se trouve derrière.

La seule règle qui garantit la sécurité

Un proxy ne peut protéger que ce qu’on ne peut pas contourner. L’application héritée doit rester inaccessible autrement que par le proxy : une règle de pare-feu interne, ou un réseau Docker dédié si l’application est conteneurisée, fait partie intégrante de l’installation, ce n’est pas une option. Si les utilisateurs peuvent encore joindre directement l’IP de l’application, la 2FA n’est que décorative.

Ce qu’il vous faut

• Un Notakey Authentication Appliance avec le service SSO intégré en fonctionnement, et les utilisateurs enrôlés dans Notakey Authenticator
• Docker sur n’importe quel hôte capable de joindre l’application
• Les enregistrements DNS et les certificats TLS pour le nouveau nom d’hôte d’entrée

L’installation, en cinq étapes

Le guide complet à copier-coller (avec les fichiers de configuration Apache et toutes les commandes) se trouve dans notre dépôt blackbox-webapp-2fa-howto. Dans les grandes lignes :

1. Générez les certificats et les métadonnées du SP SAML avec mellon_create_metadata.sh (une seule commande Docker).
2. Récupérez les métadonnées de l’IdP depuis votre service SSO.
3. Adaptez l’exemple de configuration Apache : votre nom d’hôte, l’URL de votre backend, les chemins des certificats.
4. Démarrez le conteneur du proxy et vérifiez ses journaux.
5. Enregistrez le proxy comme fournisseur de services sur la page de fédération du SSO ; l’appliance convertit les métadonnées du SP en une commande ntk cfg set prête à l’emploi.

Rendez-vous à la nouvelle adresse de l’application, approuvez la notification push, et vous avez sous les yeux votre application héritée intacte, désormais protégée par une authentification forte.

Le dépôt couvre aussi une variante optionnelle : exécuter le proxy directement sur les nœuds de l’appliance, en réutilisant leurs certificats TLS ou leur configuration ACME existants, ce qui vous évite tout hôte séparé.

Où cela s’inscrit

C’est le schéma à retenir pour tout ce qui parle HTTP. Pour le reste du parc hérité, la même appliance couvre les autres portes d’accès :

• 2FA VPN avec RADIUS : pour les concentrateurs VPN et tout ce qui utilise RADIUS
• Windows Credential Provider pour le bureau à distance : pour les connexions Windows
• 2FA SSH Linux avec pam_radius : pour les serveurs eux-mêmes