Ogni azienda ne ha una: l’applicazione web interna che manda avanti metà dell’attività, il cui fornitore è sparito da tempo o il cui codice sorgente nessuno osa più toccare, e che ora l’auditor vuole vedere protetta da un’autenticazione multifattore.
Non dovete modificarla. Non avete nemmeno bisogno di sapere in quale linguaggio è scritta. Il trucco consiste nel trattare l’applicazione come una scatola nera e nel collocare l’autenticazione a monte: un reverse proxy che parla SAML, appoggiato al servizio SSO di Notakey, in modo che ogni utente debba approvare il proprio accesso con un tocco sul telefono prima che una singola richiesta raggiunga l’applicazione.
Come funziona
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- Il browser richiede un URL protetto. Il proxy non trova alcuna sessione SAML e reindirizza al provider di identità, il servizio SSO fornito con l’appliance Notakey.
- L’utente inserisce il proprio nome utente; il server di autenticazione invia una richiesta di approvazione in notifica push sul telefono.
- Dopo l’approvazione, il browser torna con un’asserzione SAML firmata. Il proxy verifica la firma e solo allora inoltra le richieste all’applicazione.
L’applicazione in sé non cambia mai. Se dispone di una propria schermata di accesso, questa resta invariata: si aggiunge un punto di controllo a monte, senza sostituire ciò che sta dietro.
L’unica regola che ne garantisce la sicurezza
Un proxy può proteggere soltanto ciò che non si può aggirare. L’applicazione legacy deve restare irraggiungibile se non attraverso il proxy: una regola di firewall interno, o una rete Docker dedicata se l’applicazione è containerizzata, fa parte integrante dell’installazione, non è un’opzione accessoria. Se gli utenti possono ancora raggiungere direttamente l’IP dell’applicazione, la 2FA è puramente decorativa.
Ciò che vi serve
- Un Notakey Authentication Appliance con il servizio SSO integrato in funzione e gli utenti registrati in Notakey Authenticator
- Docker su un qualsiasi host in grado di raggiungere l’applicazione
- I record DNS e i certificati TLS per il nuovo hostname di ingresso
L’installazione, in cinque passi
La guida completa da copiare e incollare (con i file di configurazione Apache e tutti i comandi) si trova nel nostro repository blackbox-webapp-2fa-howto. A grandi linee:
- Generate i certificati e i metadati del SP SAML con
mellon_create_metadata.sh(un solo comando Docker). - Recuperate i metadati dell’IdP dal vostro servizio SSO.
- Adattate l’esempio di configurazione Apache: il vostro hostname, l’URL del vostro backend, i percorsi dei certificati.
- Avviate il container del proxy e controllatene i log.
- Registrate il proxy come service provider nella pagina di federazione del
SSO: l’appliance converte i metadati del SP in un comando
ntk cfg setpronto all’uso.
Andate al nuovo indirizzo dell’applicazione, approvate la notifica push e vi ritrovate davanti la vostra applicazione legacy intatta – ora protetta da un’autenticazione forte.
Il repository illustra anche una variante opzionale: eseguire il proxy direttamente sui nodi dell’appliance, riutilizzandone i certificati TLS o la configurazione ACME esistenti, così da non aver bisogno di alcun host separato.
Dove si colloca
È lo schema da adottare per qualunque cosa parli HTTP. Per il resto del parco legacy, la stessa appliance copre le altre porte d’accesso:
- 2FA VPN con RADIUS, per i concentratori VPN e tutto ciò che usa RADIUS
- Windows Credential Provider per il desktop remoto, per gli accessi Windows
- 2FA SSH Linux con pam_radius, per i server stessi