Igas ettevõttes on üks selline: sisemine veebirakendus, millel püsib pool äri, mille tarnijat pole ammu enam olemas või mille lähtekoodi ei julge keegi puutuda, ja mille audiitor tahab nüüd mitmeastmelise autentimise taha.
Te ei pea seda rakendust muutma. Te ei pea isegi teadma, mis keeles see kirjutatud on. Nipp on käsitleda rakendust musta kastina ja tuua autentimine selle ette: SAML-i kõnelev pöördproksi, mille taga töötab Notakey SSO-teenus, nii et iga kasutaja peab oma sisselogimise telefonis kinnitama, enne kui esimenegi päring rakenduseni jõuab.
Kuidas see töötab
Browser ──▶ reverse proxy (Apache + mod_auth_mellon) ──▶ legacy app
│
└──SAML──▶ Notakey SSO (IdP) ──▶ push ──▶ user's phone- Brauser küsib kaitstud URL-i. Proksi ei leia SAML-seanssi ja suunab kasutaja identiteedipakkuja juurde, SSO-teenusesse, mis on Notakey seadmega kaasas.
- Kasutaja sisestab oma kasutajanime; autentimisserver saadab tema telefoni kinnituspäringu.
- Pärast kinnitamist naaseb brauser allkirjastatud SAML-väitega. Proksi kontrollib allkirja ja alles seejärel laseb päringud rakenduseni.
Rakendus ise ei muutu kunagi. Kui sellel on oma sisselogimisekraan, jääb see alles. Lahendus lisab värava ette, mitte ei asenda seda, mis on selle taga.
Üks reegel, mis teeb lahenduse turvaliseks
Proksi kaitseb ainult seda, millest ei saa mööda minna. Vana rakendus peab olema kättesaadav üksnes proksi kaudu. Sisemine tulemüürireegel või eraldi Dockeri võrk, kui rakendus töötab konteineris, on seadistuse osa, mitte valikuline lisa. Kui kasutajad pääsevad endiselt otse rakenduse IP-aadressile, on 2FA pelgalt dekoratsioon.
Mida vajate
- Notakey autentimisseadet, millel töötab kaasasolev SSO-teenus, ning Notakey Authenticatoris registreeritud kasutajaid
- Dockerit mis tahes hostis, millest pääseb rakenduseni
- DNS-kirjet ja TLS-sertifikaate uue „esiukse“ hostinime jaoks
Seadistus viie sammuga
Täieliku, käsuhaaval järgitava juhendi, koos Apache’i seadistusfailide ja kõigi käskudega, leiate meie repositooriumist blackbox-webapp-2fa-howto. Suures plaanis:
- Genereerige SAML SP sertifikaadid ja metaandmed skriptiga
mellon_create_metadata.sh(üksainus docker-käsk). - Laadige alla IdP metaandmed oma SSO-teenusest.
- Kohandage Apache’i näidisseadistust: teie hostinimi, teie tagarakenduse URL, sertifikaatide asukohad.
- Käivitage proksikonteiner ja vaadake selle logisid.
- Registreerige proksi teenusepakkujana SSO föderatsioonilehel.
Seade teisendab SP metaandmed valmis
ntk cfg setkäsuks.
Avage rakenduse uus aadress, kinnitage tõukepäring ja teie ees ongi puutumata vana rakendus – nüüd tugeva autentimise taga.
Repositoorium kirjeldab ka valikulist varianti: proksi käivitamist otse seadme sõlmedes, kasutades nende olemasolevaid TLS-sertifikaate või ACME-seadistust, nii et eraldi hosti polegi vaja.
Kuhu see sobitub
See on muster kõigele, mis kõneleb HTTP-d. Ülejäänud pärandsüsteemide jaoks katab sama seade teised uksed:
- VPN-i 2FA RADIUS-ega, VPN-kontsentraatoritele ja kõigele, mis kasutab RADIUS-t
- Windowsi Credential Provider kaugtöölaua jaoks, Windowsi sisselogimistele
- Linuxi SSH 2FA pam_radius-ega, serveritele endile