Integratsioonid · Vanad veebirakendused

Kahefaktoriline autentimine vanadele veebirakendustele SAML-proksiga

Sisemisele veebirakendusele, millel püsib pool ettevõtte tööst, mille tarnijat enam pole või mille lähtekoodi keegi puutuda ei julge ja mida audiitor nüüd mitmefaktorilise autentimise taga näha tahab. Rakenduse ette paigutatud pöördproksi, mille taga on Notakey SSO teenus, lisab telefonikinnituse ilma rakenduse ühtegi rida muutmata.

Kuidas see ühendub

Käsitlege rakendust musta kastina

Apache’i pöördproksi koos mooduliga mod_auth_mellon paikneb rakenduse ees ja suhtleb SAML-i kaudu SSO teenusega, mis on Notakey seadmega kaasas. Kui brauser küsib kaitstud URL-i ilma SAML-seansita, suunab proksi selle identiteedipakkuja juurde. Kasutaja sisestab oma kasutajanime, autentimisserver saadab tema telefoni kinnituspäringu ja kinnitamise järel naaseb brauser allkirjastatud SAML-väitega. Proksi kontrollib allkirja ja alles siis laseb päringud läbi.

Rakendus ise ei muutu. Kui sellel on oma sisselogimiskuva, jääb see alles; lahendus lisab ette värava, mitte ei asenda seda, mis on selle taga. Te ei pea teadma, mis keeles rakendus on kirjutatud.

Proksi töötab Dockeri konteinerina igas hostis, mis rakenduseni jõuab, või otse seadme sõlmedes, kasutades nende TLS-sertifikaate või ACME seadistust, nii et eraldi hosti pole vaja.

Mida enne alustamist teada

  • Rakendus ei tohi olla kättesaadav muul viisil kui proksi kaudu. Sisemine tulemüürireegel või konteineriseeritud rakenduse puhul eraldi docker-võrk on lahenduse osa, mitte valikuline lisa. Kui kasutajad pääsevad endiselt otse rakenduse IP-aadressile, on 2FA vaid dekoratsioon.
  • Vaja on Notakey autentimisseadet, millel töötab kaasasolev SSO teenus, Notakey Authenticatoris registreeritud kasutajaid, Dockerit hostis, mis rakenduseni jõuab, ning uue hostinime DNS-i ja TLS-sertifikaate.
  • See muster sobib kõigele, mis kõneleb HTTP-d. VPN-ide, Windowsi sisselogimise ja Linuxi serverite jaoks on RADIUS- ja Credential Provideri integratsioonid.
  • Värav on rakenduse ees. Kui rakendusel jääb oma sisselogimiskuva, näevad kasutajad seda ka pärast telefonikinnitust.

Nullist esimese kinnituseni

  1. 01

    Looge SP sertifikaadid ja laadige IdP metaandmed

    Looge SAML-teenusepakkuja sertifikaadid ja metaandmed skriptiga mellon_create_metadata.sh (üks docker-käsk), seejärel laadige oma SSO teenusest identiteedipakkuja metaandmed.

  2. 02

    Kohandage Apache’i seadistust ja käivitage proksi

    Määrake hoidla blackbox-webapp-2fa-howto näidisseadistuses oma välise sissepääsu hostinimi, taustrakenduse URL ja sertifikaatide asukohad, käivitage konteiner ja kontrollige selle logisid.

  3. 03

    Registreerige proksi SSO föderatsioonilehel ja katsetage

    Registreerige proksi teenusepakkujana; seade teisendab SP metaandmed valmis ntk cfg set käsuks. Avage rakenduse uus aadress, kinnitage tõuketeavitus ja näete muutmata rakendust tugeva autentimise taga.

Korduma kippuvad küsimused

Kas rakendust ennast tuleb muuta?
Ei. Apache’i pöördproksi koos mooduliga mod_auth_mellon suhtleb SAML-i kaudu Notakey SSO teenusega ja kontrollib iga päringut. Rakendus ja selle oma sisselogimiskuva jäävad täpselt samaks.
Mida on enne alustamist vaja?
Notakey autentimisseadet, millel töötab kaasasolev SSO teenus, Notakey Authenticatoris registreeritud kasutajaid, Dockerit hostis, mis rakenduseni jõuab, ning uue hostinime DNS-i ja TLS-sertifikaate.
Kas kasutajad saavad proksist mööda minna?
Ainult siis, kui rakendus on endiselt otse kättesaadav. Sulgege see tee sisemise tulemüürireegliga või konteineriseeritud rakenduse puhul eraldi docker-võrguga; see on lahenduse osa, mitte valikuline lisa.

Juhendid ja dokumentatsioon

Seotud tooted

← Kõik integratsioonid

Esimene paroolivaba sisselogimine juba sel nädalal

30-minutiline vestlus inseneriga, mitte müügiesitlus. Paneme koos paika, kuidas teie VPN-i, SSO või Windowsi keskkonnas töötav pilootprojekt käima saab.