Toda empresa tiene una: la aplicación web interna que sostiene la mitad del negocio, cuyo proveedor desapareció hace tiempo o cuyo código nadie se atreve ya a mirar, y que ahora el auditor exige poner detrás de autenticación multifactor.
No hace falta modificarla. Ni siquiera hace falta saber en qué lenguaje está escrita. El truco consiste en tratar la aplicación como una caja negra y colocar la autenticación delante: un reverse proxy que habla SAML, respaldado por el servicio de SSO de Notakey, de modo que cada usuario deba aprobar su inicio de sesión con un toque en el teléfono antes de que una sola petición llegue a la aplicación.
Cómo funciona
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- El navegador solicita una URL protegida. El proxy no encuentra ninguna sesión SAML y redirige al proveedor de identidad: el servicio de SSO que se incluye con el Notakey Authentication Appliance.
- El usuario introduce su nombre de usuario; el servidor de autenticación envía una notificación push de aprobación a su teléfono.
- Al aprobarla, el navegador regresa con una aserción SAML firmada. El proxy verifica la firma y solo entonces deja pasar las peticiones a la aplicación.
La aplicación en sí no cambia nunca. Si tiene su propia pantalla de inicio de sesión, esta permanece igual: la solución añade una puerta delante, no sustituye lo que hay detrás.
La única regla que la hace segura
Un proxy solo puede proteger aquello que no se puede sortear. La aplicación heredada debe quedar inaccesible salvo a través del proxy; una regla de firewall interna o, si la aplicación está en contenedor, una red de Docker dedicada forma parte de la configuración, no es un extra opcional. Si los usuarios todavía pueden llegar directamente a la IP de la aplicación, el 2FA es puramente decorativo.
Qué necesita
- Un Notakey Authentication Appliance con el servicio de SSO incluido en marcha y los usuarios registrados en Notakey Authenticator
- Docker en cualquier host que pueda alcanzar la aplicación
- DNS y certificados TLS para el nuevo nombre de host de entrada
La configuración, en cinco pasos
El recorrido completo para copiar y pegar —con los archivos de configuración de Apache y todos los comandos— está en nuestro repositorio blackbox-webapp-2fa-howto. A grandes rasgos:
- Genere los certificados y los metadatos del SP SAML con
mellon_create_metadata.sh(un único comando de Docker). - Obtenga los metadatos del IdP de su servicio de SSO.
- Ajuste la configuración de ejemplo de Apache: su nombre de host, la URL de su backend, las rutas de los certificados.
- Arranque el contenedor del proxy y revise sus registros.
- Registre el proxy como proveedor de servicios en la página de federación
del SSO: el appliance convierte los metadatos del SP en un comando
ntk cfg setya listo.
Diríjase a la nueva dirección de la aplicación, apruebe la notificación push y tendrá delante su aplicación heredada intacta, ahora detrás de una autenticación fuerte.
El repositorio cubre además una variante opcional: ejecutar el proxy directamente en los nodos del appliance, reutilizando sus certificados TLS o su configuración ACME existentes, de modo que no necesita ningún host aparte.
Dónde encaja
Este es el patrón para cualquier cosa que hable HTTP. Para el resto del parque heredado, el mismo appliance cubre las demás puertas:
- VPN 2FA con RADIUS: para concentradores VPN y todo lo que use RADIUS
- Windows Credential Provider para escritorio remoto: para los inicios de sesión de Windows
- Linux SSH 2FA con pam_radius: para los propios servidores