Every company has one: the internal web application that runs half the business, whose vendor is long gone or whose source nobody dares to touch, and which the auditor now wants behind multi-factor authentication.
You don’t have to modify it. You don’t even need to know what language it’s written in. The trick is to treat the application as a black box and put the authentication in front of it: a reverse proxy that speaks SAML, backed by the Notakey SSO service, so every user must approve their login with a phone tap before a single request reaches the app.
How it works
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- The browser requests a protected URL. The proxy sees no SAML session and redirects to the identity provider, the SSO service that ships with the Notakey appliance.
- The user enters their username; the authentication server pushes an approval request to their phone.
- On approval, the browser returns with a signed SAML assertion. The proxy verifies the signature and only then passes requests through to the application.
The application itself never changes. If it has its own login screen, that stays as it is. This adds a gate in front; it doesn’t replace what’s behind it.
The one rule that makes it secure
A proxy can only protect what can’t be walked around. The legacy app must be unreachable except through the proxy. An internal firewall rule, or a dedicated docker network if the app is containerized, is part of the setup, not an optional extra. If users can still hit the app’s IP directly, the 2FA is decorative.
What you need
- A Notakey Authentication Appliance with the bundled SSO service running, and users onboarded to Notakey Authenticator
- Docker on any host that can reach the application
- DNS and TLS certificates for the new front-door hostname
The setup, in five steps
The full copy-paste walkthrough, with the Apache configuration files and every command, is in our blackbox-webapp-2fa-howto repository. The shape of it:
- Generate SAML SP certificates and metadata with
mellon_create_metadata.sh(one docker command). - Fetch the IdP metadata from your SSO service.
- Adjust the sample Apache config: your hostname, your backend URL, the certificate paths.
- Start the proxy container and check its logs.
- Register the proxy as a service provider on the SSO federation page;
the appliance converts the SP metadata to a ready-made
ntk cfg setcommand.
Browse to the app’s new address, approve the push, and you’re looking at your untouched legacy application — now behind strong authentication.
The repository also covers an optional variant: running the proxy directly on the appliance nodes, reusing their existing TLS certificates or ACME setup, so you don’t need a separate host at all.
Where this fits
This is the pattern for anything that speaks HTTP. For the rest of the legacy estate, the same appliance covers the other doors:
- VPN 2FA with RADIUS, for VPN concentrators and anything RADIUS
- Windows Credential Provider for Remote Desktop, for Windows logins
- Linux SSH 2FA with pam_radius, for the servers themselves