Jedes Unternehmen hat sie: die interne Webanwendung, an der das halbe Geschäft hängt, deren Hersteller längst vom Markt verschwunden ist oder an deren Quellcode sich niemand mehr herantraut, und die der Auditor jetzt hinter einer Multi-Faktor-Authentifizierung sehen will.
Sie müssen sie nicht verändern. Sie müssen nicht einmal wissen, in welcher Sprache sie geschrieben ist. Der Trick: Behandeln Sie die Anwendung als Black Box und setzen Sie die Authentifizierung davor: einen Reverse-Proxy, der SAML spricht und an den Notakey-SSO-Dienst angebunden ist. Jeder Benutzer muss seine Anmeldung per Fingertipp am Telefon bestätigen, bevor auch nur eine einzige Anfrage die App erreicht.
So funktioniert es
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- Der Browser fordert eine geschützte URL an. Der Proxy findet keine SAML-Sitzung und leitet zum Identity Provider weiter, dem SSO-Dienst, der mit der Notakey Appliance ausgeliefert wird.
- Der Benutzer gibt seinen Benutzernamen ein; der Authentifizierungsserver sendet eine Push-Benachrichtigung mit der Bestätigungsanfrage an sein Telefon.
- Nach der Bestätigung kehrt der Browser mit einer signierten SAML-Assertion zurück. Der Proxy prüft die Signatur und reicht Anfragen erst dann an die Anwendung durch.
Die Anwendung selbst bleibt unverändert. Hat sie eine eigene Anmeldemaske, bleibt auch die bestehen. Dieses Setup stellt ein Tor davor, es ersetzt nicht, was dahinter liegt.
Die eine Regel, die das Ganze sicher macht
Ein Proxy schützt nur, was sich nicht umgehen lässt. Die Legacy-Anwendung darf ausschließlich über den Proxy erreichbar sein: eine interne Firewall-Regel oder, bei containerisierten Anwendungen, ein eigenes Docker-Netzwerk gehört fest zum Setup und ist kein optionales Extra. Können Benutzer die IP der Anwendung weiterhin direkt ansprechen, ist die 2FA reine Dekoration.
Was Sie brauchen
- Eine Notakey Authentication Appliance mit laufendem, mitgeliefertem SSO-Dienst sowie Benutzer, die im Notakey Authenticator registriert sind
- Docker auf einem beliebigen Host, der die Anwendung erreichen kann
- DNS und TLS-Zertifikate für den neuen, vorgelagerten Hostnamen
Das Setup in fünf Schritten
Die vollständige Anleitung zum Kopieren und Einfügen (mit den Apache-Konfigurationsdateien und jedem einzelnen Befehl) finden Sie in unserem Repository blackbox-webapp-2fa-howto. Im Überblick:
- Erzeugen Sie die SAML-SP-Zertifikate und -Metadaten mit
mellon_create_metadata.sh(ein einziger Docker-Befehl). - Holen Sie die IdP-Metadaten von Ihrem SSO-Dienst.
- Passen Sie die Apache-Beispielkonfiguration an: Ihr Hostname, Ihre Backend-URL, die Zertifikatspfade.
- Starten Sie den Proxy-Container und prüfen Sie seine Logs.
- Registrieren Sie den Proxy als Service Provider auf der
Föderationsseite des SSO. Die Appliance wandelt die SP-Metadaten in
einen fertigen
ntk cfg set-Befehl um.
Rufen Sie die neue Adresse der App auf, bestätigen Sie den Push – und vor Ihnen liegt Ihre unveränderte Legacy-Anwendung, jetzt hinter starker Authentifizierung.
Das Repository beschreibt auch eine optionale Variante: den Proxy direkt auf den Appliance-Knoten zu betreiben und deren vorhandene TLS-Zertifikate oder das ACME-Setup mitzunutzen. Dann brauchen Sie gar keinen separaten Host.
Einordnung
Dieses Muster eignet sich für alles, was HTTP spricht. Für den Rest des Legacy-Bestands deckt dieselbe Appliance die übrigen Türen ab:
- VPN-2FA mit RADIUS: für VPN-Konzentratoren und alles, was RADIUS spricht
- Windows Credential Provider für Remotedesktop: für Windows-Anmeldungen
- SSH-2FA unter Linux mit pam_radius: für die Server selbst