Integrations · Legacy web applications
Two-factor authentication for legacy web apps with a SAML proxy
For the internal web application that runs half the business, whose vendor is gone or whose source nobody dares to touch, and which the auditor now wants behind multi-factor authentication. A reverse proxy in front of it, backed by the Notakey SSO service, adds the phone approval without modifying a line of the app.
How it connects
Treat the application as a black box
An Apache reverse proxy with mod_auth_mellon sits in front of the application and speaks SAML to the SSO service that ships with the Notakey appliance. When the browser requests a protected URL with no SAML session, the proxy redirects to the identity provider. The user enters their username, the authentication server pushes an approval request to their phone, and on approval the browser returns with a signed SAML assertion. The proxy verifies the signature and only then passes requests through.
The application never changes. If it has its own login screen, that stays as it is; this adds a gate in front rather than replacing what is behind it. You do not need to know what language the application is written in.
The proxy runs as a Docker container on any host that can reach the application, or directly on the appliance nodes, reusing their TLS certificates or ACME setup so no separate host is needed.
What to know before you start
- The application must be unreachable except through the proxy. An internal firewall rule, or a dedicated docker network if the app is containerised, is part of the setup, not an optional extra. If users can still reach the app’s IP directly, the 2FA is decorative.
- You need a Notakey Authentication Appliance with the bundled SSO service running, users onboarded to Notakey Authenticator, Docker on a host that can reach the application, and DNS and TLS certificates for the new hostname.
- This is the pattern for anything that speaks HTTP. VPNs, Windows logins and Linux servers use the RADIUS and credential-provider integrations instead.
- The gate is in front of the application. If the app keeps its own login screen, users still see it after the phone approval.
From zero to the first approval
- 01
Generate SP certificates and fetch the IdP metadata
Create the SAML service provider certificates and metadata with mellon_create_metadata.sh (one docker command), then fetch the identity provider metadata from your SSO service.
- 02
Adjust the Apache configuration and start the proxy
Set your front-door hostname, the backend URL and the certificate paths in the sample configuration from the blackbox-webapp-2fa-howto repository, start the container and check its logs.
- 03
Register the proxy on the SSO federation page and test
Register the proxy as a service provider; the appliance converts the SP metadata into a ready-made ntk cfg set command. Browse to the application’s new address, approve the push, and you are looking at the untouched application behind strong authentication.
Frequently asked questions
- Does the application itself have to change?
- No. An Apache reverse proxy with mod_auth_mellon speaks SAML to the Notakey SSO service and gates every request. The application and its own login screen stay exactly as they are.
- What do I need before I start?
- A Notakey Authentication Appliance with the bundled SSO service running, users onboarded to Notakey Authenticator, Docker on a host that can reach the application, and DNS and TLS certificates for the new hostname.
- Can users bypass the proxy?
- Only if the application is still reachable directly. Block that with an internal firewall rule, or a dedicated Docker network if the app is containerised; this is part of the setup, not an optional extra.
Guides and documentation
Related products