Intégrations · Applications web héritées
Authentification à deux facteurs pour applications web héritées, via un proxy SAML
Pour l’application web interne qui fait tourner la moitié de l’entreprise, dont l’éditeur a disparu ou dont personne n’ose toucher le code source, et que l’auditeur veut désormais voir protégée par une authentification multifacteur. Un reverse proxy placé devant elle et adossé au service SSO de Notakey ajoute l’approbation sur le téléphone sans modifier une seule ligne de l’application.
Comment s’établit la connexion
Traiter l’application comme une boîte noire
Un reverse proxy Apache doté de mod_auth_mellon se place devant l’application et dialogue en SAML avec le service SSO fourni avec l’appliance Notakey. Lorsque le navigateur demande une URL protégée sans session SAML, le proxy le redirige vers le fournisseur d’identité. L’utilisateur saisit son nom d’utilisateur, le serveur d’authentification envoie une demande d’approbation sur son téléphone et, une fois la demande approuvée, le navigateur revient avec une assertion SAML signée. Le proxy vérifie la signature et ne laisse passer les requêtes qu’à ce moment-là.
L’application ne change jamais. Si elle possède son propre écran de connexion, celui-ci reste tel quel : on ajoute un contrôle en amont au lieu de remplacer ce qui se trouve derrière. Inutile de savoir dans quel langage l’application est écrite.
Le proxy s’exécute en conteneur Docker sur tout hôte capable de joindre l’application, ou directement sur les nœuds de l’appliance, en réutilisant leurs certificats TLS ou leur configuration ACME : aucun hôte supplémentaire n’est nécessaire.
À savoir avant de commencer
- L’application ne doit être accessible qu’à travers le proxy. Une règle de pare-feu interne, ou un réseau docker dédié si l’application est conteneurisée, fait partie de la configuration et n’a rien d’optionnel. Si les utilisateurs peuvent encore joindre directement l’IP de l’application, la 2FA n’est que décorative.
- Il vous faut une Notakey Authentication Appliance avec le service SSO intégré en fonctionnement, des utilisateurs enrôlés dans Notakey Authenticator, Docker sur un hôte capable de joindre l’application, ainsi qu’un enregistrement DNS et des certificats TLS pour le nouveau nom d’hôte.
- Ce modèle s’applique à tout ce qui parle HTTP. Les VPN, les connexions Windows et les serveurs Linux passent plutôt par les intégrations RADIUS et credential provider.
- Le contrôle se situe devant l’application. Si celle-ci conserve son propre écran de connexion, les utilisateurs le voient toujours après l’approbation sur le téléphone.
De zéro à la première approbation
- 01
Générer les certificats SP et récupérer les métadonnées de l’IdP
Créez les certificats et les métadonnées du fournisseur de services SAML avec mellon_create_metadata.sh (une seule commande docker), puis récupérez les métadonnées du fournisseur d’identité auprès de votre service SSO.
- 02
Adapter la configuration Apache et démarrer le proxy
Renseignez votre nom d’hôte d’accès, l’URL du back-end et les chemins des certificats dans la configuration d’exemple du dépôt blackbox-webapp-2fa-howto, démarrez le conteneur et consultez ses journaux.
- 03
Enregistrer le proxy sur la page de fédération SSO et tester
Enregistrez le proxy comme fournisseur de services ; l’appliance convertit les métadonnées SP en une commande ntk cfg set prête à l’emploi. Rendez-vous à la nouvelle adresse de l’application, approuvez la notification push : vous voilà devant l’application intacte, désormais derrière une authentification forte.
Questions fréquentes
- Faut-il modifier l’application elle-même ?
- Non. Un reverse proxy Apache doté de mod_auth_mellon dialogue en SAML avec le service SSO de Notakey et contrôle chaque requête. L’application et son propre écran de connexion restent exactement tels quels.
- De quoi ai-je besoin avant de commencer ?
- D’une Notakey Authentication Appliance avec le service SSO intégré en fonctionnement, d’utilisateurs enrôlés dans Notakey Authenticator, de Docker sur un hôte capable de joindre l’application, ainsi que d’un enregistrement DNS et de certificats TLS pour le nouveau nom d’hôte.
- Les utilisateurs peuvent-ils contourner le proxy ?
- Seulement si l’application reste joignable directement. Bloquez cet accès par une règle de pare-feu interne, ou par un réseau docker dédié si l’application est conteneurisée : cela fait partie de la configuration, ce n’est pas une option.